>On Wednesday, March 6, 2002, at 08:02 PM, John M McIntosh wrote:
>
>>c) Use of Carbon event logic for OS-X only. This is a major 
>>structural change.
>>
>>It also encouraged the use of a pthread for interp.c.
>
>Yes  ;-)
>
>What would be even nicer, though, is if Squeak were made passive. 
>This would allow true event-based logic without forcing the use of 
>threads, which has its own problems.
>
>Marcel

I've not sure what you mean by making it passive? But let me ramble on.

Right now the main thread blocks on RunApplicationEventLoop.
The pthreaded inter.c spins, and perhaps does a usleep() (which is a 
pthread delay). When events come in they wake up the main thread, and 
it using the proper pthread semaphore adds the event or meta event to 
the squeak vm event queue. Which at somepoint pulls them off the 
queue, and how?

Well Squeak is busy in EventSensor polling (yes polling) for 
events... But that effort usually results in a cpu load of < 10% when 
idle. Mmm maybe we could have a indicator if the VM actually supports 
a *true* event driven model. Then have the EventSensor wait forever 
on the squeak event semaphore, versus do the polling. Although there 
*is* an event sensor semaphore I'm not aware any VM actually signals 
it... (OK I think I'll try it just for interest sake)

Also see
http://developer.apple.com/qa/qa2001/qa1061.html for a complicated 
solution. The issue is RunApplicationEventLoop blocks and dispatchs 
events to interested parties then sleeps.

Also see
http://developer.apple.com/techpubs/macosx/Carbon/oss/CarbonEventManager/Carbon_Event_Manager/Tasks/Executing_the_Event_Loop.html

-- 
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================