> I think it's because main thread have slightly higher priority in  
> windows.

Ah, that reminds me, you cannot do UI work on anything other than the  
main thread in carbon and I think
Cocoa applications in os-x.

When we migrated from InputSensor to EventSensor I had changed th pre- 
os-x (OS8.x) squeak VM to use cooperative threading which allowed us  
to run the
VM on one thread, and the UI on another.  This was changed when OS-X  
came out to run the interpret() on a pthread with the main pthread  
handing the UI.
The UI thread used some mutex semaphores to place data on the VM event  
queue. All was happy, but Apple started enforcing the rules about UI  
calls only on the main thread.

Although I had a lockUI call to swap the call or FFI call to the main  
thread which worked quite well, Sophie started getting serious about  
FFI calls to quicktime we ran into major problems
with it's usage of Open/GL.

This was fixed in 3.8.12b1 when I switch to dispatching the  
interpreter loop via a carbon event and back to a form of co-operative  
threading.
Mac Carbon 3.8.12b1 Alter VM so that the interpreter() loop is  
dispatched on the UI thread and we poll for pending UI events. This is  
to allow quicktime FFI calls to work on the main thread that contains  
the UI, and to avoid cross thread OpenG/L calls which seem to crash  
the VM

I note this because someday someone might want to make a UI related  
FFI call on a Hydra thread and then something unexpected could  
happen.  More research required to understand if this is an issue with  
Cocoa applications.
--
= 
= 
= 
========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================