On Thursday 08 February 2001 13:46, Stefan Matthias Aust wrote:

> I see.  Actually I think it's also important that sockets signal
> events.  When using Swiki I noticed that there was a noticable difference
> in the response time whether my mouse was inside the Squeak window or not.
>
> I think, when I didn't provide input events to the VM, the VM tried to be
> nice to the system and went into delay mode.  This unfortunately also means
> that sockets are polled less often and so the response time of the swiki
> goes up.

That's interesting; have you tried it recently? There's a delay mode built in 
to the UI for input (keyboard/mouse) events, but higher-priority threads 
should still run, right? And the socket polling happens from deep inside the 
VM, so if you're executing bytecodes at all, you should get sockets checked.

Sound, serial, MIDI, etc. should also be event-driven. The serial support 
skirts this by never blocking on a receive -- it always returns immediately 
from a receive, possibly with no characters.

But I'd rather see a semaphore signaled so I don't have to have a polling 
loop in Smalltalk to do serial support.

Even getting polling right across plugins is a challenge. Ideally, you'd be 
able to add a plugin without editing anything else, and it'd get called 
periodically from the interpret loop to check for events.

As I remember, Lex Spoon made some changes to the Unix VM
"so that any part of the VM -- including plugins
-- may now register file descriptors to be checked with select()
whenever ioRelinquishProcessor() is called." These are at
         http://www.cc.gatech.edu/~lex/squeak/

Unfortunately, this isn't general enough, since some plugins may need to do 
something beyond just calling select() on file handles. And Windows doesn't 
use select() for arbitrary file handle checking (just for sockets).

-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com