>I have a problem that reminds me of the discussion of Squeak's network
> semaphores.  Google was somewhat informative, but spawned additional
> questions.
>
> Is it fair to say that the network semaphores are essentially flow
> control devices that would be transparent to users of read and write
> streams connected to a socket?

Eh, yeah. They are transparent to users of Socket directly too. :) 
Semaphores are used in many places in Squeak to communicate with stuff 
going on in parallell outside Squeak - typically in separate OS 
threads in the VM and plugins.

So regarding Socket - the VM does reading/writing to the low level OS 
socket in the Socket plugin - running in a (or more) separate OS 
thread(s) in the plugin. So the low level reading/writing goes on

*parallell* to the regular Squeak interpreter execution.

Getting bytes into and out from Squeak is done using buffers and the 
semaphores. Each Socket instance has 1 (or 3 depending on platform) 
semaphores that it uses so that it doesn't have to busy loop and poll 
the plugin (Got data? Got data? Got data? etc... :) ).

An example is Socket>>waitForDataIfClosed:. As you see first we call a 
prim to see if there is any data we can call the plugin to get. If 
there is none we first use another prim to see that we are still 
connected. If we are (and should be able to get more data) - then we 
use the semaphore to wait and when we get wakened up we check again if 
there is any data (there should be).

When we wait on a Semaphore (for readers that don't know diddly squat 
about Semaphores) the running Squeak Process is kept on hold and thus 
consumes no CPU. Semaphores are the basic low level building stone in 
Squeak (and most languages) for synchronizing both between Squeak 
Processes and between Squeak Processes and the outside world 
(VM/plugins). For programmers there is a now a higher level building 
block called Monitor. Haven't played with it yet - but it is easier to 
use. Programming intricate stuff using Semaphores is quite hard - my 
SharedStreams package mentioned below shows that. When I (and Jonas) 
wrote it we had to think hard to get it all right - and perhaps it 
still has bugs. SharedQueue in the image I believe still has some bugs 
(and should IMHO be replaced with SharedStreams), but not many people 
use that class.

As you can see users of Socket instances never care about the semas. 
But using Socket "raw" is still pretty complicated - best for most 
cases I have seen is to wrap it in a stream like wrapper and use the 
streaming protocol instead. SocketStream is such a wrapper. It isn't 
like a regular stream, because it has a separate input and output 
"channel" - but it does support the streaming methods.

Now two things worth mentioning:

1. My SharedStreams package on SM has a class called 
   SharedBidirectionalStream. It acts just like a SocketStream does - 
   but can be used between Squeak Processes. It is quite cool - look 
   at the examples.

2. I am releasing a new implementation of SocketStream later today. It 
   isn't much different from the outside - but it is "better" in most 
   respects.