This has been discussed before, but no agreement came out of that 
discussion. The problem with my making changes to this behavior in 
Unix is that it would have to be ported to every platform.

I hesitate to call this a [BUG]; it's more of a design malfeature.

Now that we have the sqaio support for sockets, why aren't we using it 
for regular file handles and for serial I/O?

For instance, if you even try to open a Unix fifo for read, all of 
Squeak locks up until there is data ready to read on that fifo. And 
every time you do a read Squeak locks up as well until data is 
available. So reading from fifos is effectively impossible with the 
standard file support.

And the serial port support was written to be explicitly non-blocking, 
forcing us to poll (which is pretty ugly).

My problem with fixing this is that it would affect the FilePlugin and 
the SerialPlugin, and would change the API of the SerialPlugin. Which 
would affect everyone using it.

The serial code would have to have an API added for timeouts, so that 
existing code could still get 0 bytes back from a read on a timeout.

The Unix and the Windows APIs allow for setting character and read 
timeout values.

What I'd like to see is for the reads or writes on files and serial 
ports to block the calling thread until complete or timed out.

An alternative, of course, would be to come up with a NewSerialPlugin 
and a NewFilePlugin that do the right thing.

Any thoughts on this?
-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE