Craig,

[Blocking vs. non-blocking parts deleted]
> > ...bypassing these checks can get you in a tight spot since the
> > blocking VM call will stop Squeak completely and because of this
> > I'd rather go for non-blocking sockets here...
> 
> 	Huh? If you're doing the work in a host thread, the 
> main VM process is unaffected. That's why I use threads. Make 
> the host kernel earn its existence! :)

Eh?! Excuse me?! You are *not* doing the work in the OS threads. You are
watching state changes in the OS thread (as you point out yourself in two
different paragraphs of your email; one of them directly relating to my
initial wrong assumption that you would do the work in OS threads). recv()
and send() are called directly from the primitive, e.g., recv() from
nextIntoStartingAtTCPSocket and send() from nextPutFromStartingAtTCPSocket -
unless you have changed the primitives over the last two days. If any of
these calls block your VM stands still and does absolutely nothing! And if
you start doing work in the threads let me tell you that terminating the
threads from out the outside will leave enough resources open so that at
some time you will run out of handles on the OS (this is what happened to
me...) which leaves you again with exactly one choice: non-blocking sockets.

> > From all of the above it is clearly the case that there is no actual
> > need to get away from the current set of primitives for any
> > functional reasons.
> 
> 	I don't think that follows at all. I suppose we're 
> discarding the simplicity-of-implementation point by default 
> (deep sigh), but, further, you're implicitly accepting the 
> suboptimal performance of the current design.

The above clearly states 'for any *functional* reasons'. I am not at all
opposed to simplicity or beauty but you seemed to be saying that there are
fundamental functional differences which is not the case at all.

> > ...my recommendation is to stay with the current primitive set and 
> > consider an inclusion of the optional primitive 'Socket>>signal: 
> > aSemaphoreIndex forOperation: opCode timeout: timeOutMSecs
> > socket: socketHandle' from the correspondents framework...
> 
> 	Well, this would certainly be a lot better than the status quo.

The status quo is actually quite sufficient. Just to prove my point I have
rewritten the Windows socket primitive implementation yesterday to be as
responsible as yours on the VM level [Implementors note: The idea is that
the VM *does* actually know what state changes are of interest; e.g.,
changes from readable to non-readable and writable to non-writable can only
occur when data is read/written which can be determined by the VM and a
state watcher (running in a separate thread) can be activated once this
happens. Pretty simple...]

  Andreas