Besides, signalling the event semaphore from the VM will only work if you have a multi-threaded VM implementation which can process incoming UI events in parallel to the VM's loop. If you don't, then you'll only get new events every 500ms or so (depending on what your VM interrupt check counter says) so not stimulating the input semaphore is not an option given all the non-multithreaded implementations.
Well yes the mac os-x VM is a muti-threaded VM that has a separate thread for the UI events. That's part of the carbon/cocoa event model. In fact the UI thread uses pthread locking to deposit events onto the Squeak VM thread.
What I've done as a first pass is create a message to replace the inputSemaphore signal, that way one can check out doing a Delay waitFor 1 millisecond to see how that affects cpu load.
As a subclass I've created a EventSensorVMDriven class which does nothing for the inputSemphoreSignal method, and relies on the mutli-threaded event driven VM to signal the semaphore when events actually are constructed and placed on the VM event queue. As part of the EventSensor install command I install the correct class based on the OS type and version information.
This seems to work fine. Others are welcome to try it and give feedback on how it feels or if there are issues. Certainly I would like to hear about issue on multi-cpu macintoshes.
Please ensure the global Sensor is the right class after you've filed in and installed the changes.
Technically I can move towards this model on OS-9 too because it's pseudo -threaded underneath, but the signal inputSemaphore has been commented out for many years...
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===