Craig Latta wrote:

> One could do the checks in the C code of the primitive, but that 
> wouldn't make things go any faster.

	If you've got host threads focusing on specific events for you, some of the checks aren't even necessary.

The cost of an extra test in the Smalltalk code once per incoming
packet is utterly insignificant relative to the overhead of
transferring the data.

What *would* be inefficient would be a busy loop polling the socket
status. However, such polling isn't needed because the client waits
on the semaphore until something actually happens.


Craig Latta wrote:
>	At http://netjam.org/correspondents/advocacy.html I write:
>
>> [Currently] there is only one Smalltalk semaphore provided for 
>> synchronization with all a socket's network events. It's possible
>> to get a writeability signal while waiting for readability, and
>> vice-versa. Also, one cannot wait for both at the same time. It is 
>> therefore not possible to correctly implement protocols in which
>> separate Smalltalk Processes read from and write to a socket. The 
>> implementation requires that correctly-functioning protocols which 
>> use it will read and write sequentially in a single Smalltalk Process, 
>> consume all available incoming data before writing, and finish writing 
>> before new incoming data arrives. This is okay for simple call-response 
>> protocols like POP, but not for more complex ones like IRCP. 
>
>	Why do you disagree with this?

Because there are several ways to allow one Squeak thread to
wait for reading independently of another thread that is waiting
for writing. One way to do it is to create two additional semaphores
which are waited on by the readers and writers. An additional
Squeak thread waits on the socket semaphore. When it is awoken,
it checks for both data available and space available for
writing, and signals the appropriate semaphore(s). You could
also do the same without the additional thread, althought it's
slightly messier to code--the read code needs to signal the
write semaphore and vice versa.

There is a third approach, although it
isn't quite fair to use it in this argument because it requires
changing the VM. That is to have the VM awaken *all* processes
waiting on the semaphore whenever the socket semaphore is signalled.
(This is sometimes called a "broadcast" semaphore.) Each waiting
process then checks to see if the condition it is waiting for
(dataAvailable or sendDone) has been fulfilled. This is actually
the approach I had in mind when I designed the primitives, but
we were in a rush to get something out (as usual), so I didn't
put in the broadcast support, figuring I'd add it when it was
needed. We've gotten surprisingly far without it, but I think that
it's the solution that I prefer since it simplifies the coding
of the Smalltalk side (no extra thread is needed, and the code
for reading and writing is quite independent).

Since I know of several ways to do it, I must disagree with your
statement that:

	It is therefore not possible to correctly implement
	protocols in which separate Smalltalk Processes read
	from and write to a socket.

Not obvious, perhaps. But not at all impossible.

	-- John