Ok, tthe TheInterruptSemaphore is signalled in checkForInterrupts()
via usage of setInterruptPending().
As far as I know the only place that it is used is by the VM host
platform keyboard handling logic
only *IF* you are using an image that predates EventSensor (Aug 2000)
Now since most people use an image that has this class what happens is
(a) The process running EventSensor>>processEvent: looks at the
incoming VM generated keyboard event and
if it decides that the keys pressed meet it's criteria of what an
interrupt is then it signals in the EventSensor interruptSemaphore
That then wakes up the interrupt watcher process
InputSensor>>userInterruptWatcher
running at Processor lowIOPriority.
This means of course the process that is running
EventSensor>>processEvent: has to be able to run.
You could simplify things here and fork off the userInterruptWatcher
logic in EventSensor>>processEvent:
and as I think Michael noticed rip out the InterruptWatcherProcess and
InterruptSemaphore
On 20-Nov-08, at 7:18 AM, Igor Stasenko wrote:
2008/11/20 Michael Rueger <[EMAIL PROTECTED]>:
Igor Stasenko wrote:
If i remember correctly, an interrupt semaphore is used to awake a
process which watching for interrupts.
And indeed, when key combination matching an interrupt key code,
it calls setInterruptPending(), which is then eventually leads to
signaling a semaphore which registered as interrupt semaphore.
You can't handle it on image side, because you may not have chance
to
get to it (if there's another process running on same or higher
priority than event ticker process).
While in VM, regardless what image does, it periodically checks for
interrupts, and during handling OS events, it checks if an interrupt
key pressed, and if so, then signals the semaphore.
At least, this is how it looks on Win32.
The question really was if it is in the VM but rather if it (still)
should
be in the VM.
After some discussions with John I'm pretty sure we can remove the
interrupt
semaphore code from the VM. For now that would mean that the image
code
still referring to it should/can be removed.
In this case, i'd like to read John's reasoning, why its safe to
remove it from VM.
From my perspective , it should stay, because you can't imitate same
behavior on language side safely.
Michael
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
=
=
=
========================================================================
John M. McIntosh <[EMAIL PROTECTED]>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
