Well the scheduling rules are the same, but on the os-x carbon VM I've used pthreads to separate the UI from the running of the VM.
Tapping the interrupt key always will be immediately noticed by the UI thread which deposits the keystroke on the VM event queue. In this case the interpreter pthread is grinding away most likely doing a full GC trying to find some memory.
The interpreter pthread of course needs to grind thru the bytecodes to get to the point of grabbing the events from the VM event queue and them processing the interrupt key. I do signal the inputSemaphoreIndex semaphore which is the event queue semaphore, but not sure if that helps any in this case. However that should cause the high priority eventsensor task to wakeup immediately and process the interrupt key stroke.
Can't say why the unix one doesn't have the same behaviour. I wonder the the path length to get the X11 handleEvent() logic is so long or never gets to run so you perhaps you aren't waiting long enough for the keystroke to be polled for?
On Sunday, September 7, 2003, at 11:13 AM, Avi Bryant wrote:
On Sun, 7 Sep 2003, Michael Fremont wrote:
I've tried Avi's code; it's really nice, simple code. Unfortunately, on very fast machines on Unix, it gets into some kind of infinite loop of error notifications that cause the Emergency Evaluator to pop up when you test it with:
Smalltalk createStackOverflow.
Hm, you're right - I can't get it to work at all on Linux. I wrote and tested it on Mac OS X, where it worked fine.
A recursive loop seems to lock the unix VM *much* harder than it was locking the Mac OS X VM - the interrupt key doesn't work, UI events don't get through - even when the offending process is forked at the lowest priority.
Inserting a call to "Processor yield" into #createStackOverflow fixes these problems. Are the scheduling rules different between VMs?
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===