Hi Ned,

Async serial and async file pose very similar problems.  Would it help if
I were to spend a day implementing the the async file support?  I would
expect you to be able to adapt and/or simply share quite of bit of the
same code in an async serial implementation.  (To the support code, "it's
all just descriptors". ;-)

> * block on reads or writes (note that writes are likely to be buffered 
> by the OS)

You'd probably want to make this work like sockets.  Do the i/o in
nonblock mode and use the semaphore(s) to signal the image when read data
and/or write space are available.  The aio handlers should end up looking
very similar to the socket ones.

On the other hand, since you're starting from a clean slate, you have the
chance to get the image/support interface _right_ w.r.t. to semaphores
and signals.  (Don't forget that Unix select()s on a descriptor for write
when there is as little as one byte free in the underlying buffer.  It's
best if the support code can determine with absolute precision when the
image is waiting on a semaphore and when it isn't.  Simply select()ing all
the time on a writable descriptor will keep Squeak in a very nasty busy
loop.)

> I don't know whether it would be a good idea to have separate 
> semaphores for reading and writing, though I suspect that I'd like 
> this.

There are arguments in both directions.  (I recently talked [read: argued
;-] with Andreas and Lex about the pros and cons of 3- versus 1-semaphore
models in the socket code.)  Having two semaphores makes independent
treatment of input and output a lot easier (you can have two separate
processes, one for each direction -- think "telnet client") but makes
single-process full-duplex harder (since sometimes what you really want to
do is wait on two semaphores simultaneously -- and this isn't possibile in
one process without either VM modifications [aSema waitWith: anotherSema]
or two other processes which do nothing but wait on the read/write
semaphores and then signal a third semaphore which tells you that one of
the others has been signaled -- *ouch*! ;).

The situation is just the opposite for the 1-semaphore model (but you'd
also have to poll both read and write to find out which of the directions
has caused the signal).

Whichever way you do it you risk having to implement explicit
"multiplexing" and "demultiplexing" of signals inside the image, depending
on design decisions made in client apps.

> Do any of you see a need for such a plugin?

Might something like this be of help MIDI at all?

> Anyone want to help?

I'm happy to write the async file support, from which you should be able
to bootstrap the async serial support more easily than doing it in-vacuo.

Regards,

Ian