goran.hultgren at bluefish.se wrote:
> We use Comanche with SocketStream and my problem is that this method:
> 
> waitForDataUntil: deadline
> 	"Wait up until the given deadline for data to arrive. Return true if
> data arrives by the deadline, false if not."
> 
> 	| dataArrived |
> 	[self isConnected & 
> 	 (dataArrived _ self primSocketReceiveDataAvailable: socketHandle) not
> 			"Connection end and final data can happen fast, so test in this
> order"
> 		and: [Time millisecondClockValue < deadline]] whileTrue: [


This method should surely check if the socket is still connected. 
waitForDisconnectionUntil: has a similar problem, and has been fixed in
Comanche.  The patches never got extracted for inclusion in the main
image.  At a quick glance, waitForDataUntil: doesn't seem to have been
patched by Comanche, but the problem looks identical.

By the way, waitForDataUntil: should certainly return if the socket
closes.  And for that to hapen, the read semaphore will need to be
signalled even though, strictly, there is no data available for reading.
 select() and read() behave just like this in the sockets API.  We could
do much worse than simply mimicking the sockets API wherever we have no
particular reason to do anything else.


But, it seems from your later example that it is not invalid sockets,
after all.  Ho hum.  Honestly I have never traced through the semaphore
signalling stuff in the Unix VM, and never really understood what the
three (or is it two?) semaphores actually mean, anyway.


Lex