John M McIntosh <johnmci at smalltalkconsulting.com> is widely believed to have written:


> Well the reason the signal semaphore is commented out is because
> 
> EventSensor>>ioProcess
> 	"Run the i/o process"
> 	| eventBuffer type |
> 	eventBuffer _ Array new: 8.
> 	[true] whileTrue:[
> 		[self primGetNextEvent: eventBuffer.
> 		type _ eventBuffer at: 1.
> 		type = EventTypeNone] whileFalse:[self processEvent: 
> eventBuffer].
> 		inputSemaphore waitTimeoutMSecs: EventPollFrequency.
> 		Preferences higherPerformance ifTrue: [
> 			EventPollFrequency _ (EventPollFrequency * 
> 1.5) rounded min: 500.
> 		].
> 	].
> 
> What happens here is that if primGetNextEvent doesn't return an event 
> then we wait 20ms and try again. So technically we are polling... 
> Because of this having the signal semaphore isn't really required in 
> the Mac VM.

The reason the code is like this is so that it can support both sorts of
vm/os; if you are able to write a vm that can _really_ signal the
semaphore from an interrupt or thready-thing then obviously the timeout
will be ignored whenever such an event happens. On a vm/os with no
thready-stuff, the timeout will keep things going tolerably.

There should be nothing to stop you signalling the semaphore in only
some cases either; I think it might work if you wanted to immediately
signal when the unix socket sem was tickled for example. You could even
have an OS event tickle it on a regular time basis, thus overriding the
Squeak delay setting. Or not.

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Use free-form input where possible.