Dear Craig,

Let's try to calm down this discussion a bit and review what I was saying:
The point I am trying to make is that as long as you don't know exactly how
many bytes you can read or write from a socket any call to a blocking send()
or recv() from a primitive may stop your entire VM. I think you agree on
that since it has been pointed out by a different poster (thanks for giving
a detailed explanation). 

Because of this, I think it is very unwise to use blocking sockets. For a
Smalltalk server, there is always the chance that *some* calls may block
(when the server is really busy all possible and inpossible constellations
may occur) which will in the best case slow down the response times. And
your entire design is directed towards fast response times so that doesn't
seem to be a good idea to me. I hope you can agree on this part in general.
While it might be the case that one can eventually find out *exactly* how
many bytes can be read/written this may be different across platforms (and
even different on various Windows version) so that a general recommendation
for socket primitive implementors to use blocking sockets seems to be
unwise.

Let me also try to outline what I was referring to in one of my previous
posts: How to make the current socket primitives as responsible as your
design. What we are interested in are state changes of the socket. There are
basically four different state changes that may occur: From readable to
non-readable, from non-readable to readable, from writable to non-writable
and from non-writable to writable (for the sake of simplicity I will
concentrate on data transmission here not on connection establishment). It
is clear that a state change from readable to non-readable can only occur
during an actual data transfer in a Squeak primitive (e.g., in
sqSocketRecv...) since that is the only place where data is read from a
socket. The same is true for changes from writable to non-writable which can
only occur in sqSocketSend... When using non-blocking sockets the change can
be implicitly detected by observing the number of bytes read/written; e.g.,
whenever there was less data read from a socket than would fit into the
buffer there is no more data available (readable -> non-readable) or
whenever less data was written than in the buffer no more data can be
written at this time (writable -> non-writable).

After any one of these changes has occured, the VM can safely assume that
the state change being of interest is that from non-readable to readable, or
non-writable to writable (depending on the previous operation of course). At
this very point, the VM can activate 'state watcher threads' which do what
your threads do: Performing a blocking select() on the socket and go to
sleep until something changes in the state of the socket. When the state
changes, these watchers signal the associated socket semaphore and go to
sleep (using an event or similar mechanism) until the next read/write
operation indicates a change in socket state again and activates the watcher
again.

> 	Your statements above are pointlessly insulting and 
> sarcastic, not at all what I would expect from the Squeak 
> Team. They are uncalled for. Please don't speak (write) to me 
> that way.

I apologize. It is sometimes hard to realize that we are discussing this
issue in public (I would very much prefer to solve it in private
conversation).

  Andreas