Hi Bill!

"Bill Schwab" <BSchwab at anest.ufl.edu> wrote:
> Hello,
> 
> 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. :)

> Is there any relevant theory that I should study?  Any pointers to
> literature?

I dunno. But if you hook up to irc.freenode.org, channel #squeak I am
there :).

regards, Göran