On Wed, Jun 25, 2003 at 02:27:47PM +0300, Lex Spoon wrote:
> "David T. Lewis" <lewis at mail.msen.com> wrote:
> > On Tue, Jun 24, 2003 at 09:20:53PM -0700, Alan Grimes wrote:
> 
> > > 1. Because the current squaek system is single-threaded, it will need to
> > > block and sit on the read(); call or poll it... neither solution is
> > > especially great... 
> > 
> > This is not as bad as it seems. You have to avoid blocking the VM on
> > an external IO operation, but it turns out that this can be handled
> > (at least on some platforms) with the "aio" event mechanism in Ian's VM,
> > combined with some primitive support to forward IO events to the
> > Squeak VM (the primitives are in the currently released OSProcess
> > plugin, but image-side support is stuck in the aforementioned stuff
> > that won't yet pass my SUnit tests).
> 
> 
> What do you mean, David?  Look at methods like waitForDataUntil:, and
> you can see code that waits on a signal from the VM.  On Unix, at least,
> that signal comes from the aio module, which in turn uses Unix's
> select(2).  This functionality seems to be available from the image, if
> you want it.  Does OSProcess have its own sockets interface?

Yes, sockets do this. But the aio mechanism works fine for files, pipes,
and other IO channels, so it does not need to be specific to socket IO.
All you need to do is wire up the aio event to signal a Squeak semaphore,
and you have an IO event notification mechanism that works in a much more
general way.

No, I have not touched the sockets interface in Squeak. For the moment I
am mainly interested in using aio events from /dev/tty or from a pipe.
But IMHO it would be nice if Squeak can start using IO channels without
worrying quite so much about whether the channel is a "socket" or a
"file" or whatever.

> I disagree that you need to use this kind of thing, though.  Polling is
> fine for a telnet server: just pick a polling interval of 100 times per
> second, and the user won't notice the lag and the CPU load will be
> extremely low.

I can't disagree with this. I've spent much too much time making a fully
event-driven CommandShell, and I'm still not sure it is worth the trouble.
At the moment, it looks like the result will be somewhat more responsive
feeling and simpler in some respects than the polling version, but it has
been very difficult to debug the event-driven stuff (and it would have
been nearly impossible without Ned's ProcessBrowser).

Dave