Problem with Socket under Linux...

Andreas Raab Andreas.Raab at
Sat Apr 27 22:33:56 UTC 2002


> This method should surely check if the socket is still connected. 

Whaddayamean "it should check"?! The first line says:

> > 	[self isConnected & 

and so it surely _does_ check if the socket is connected ;-)

> 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.

Yes, these kinds of problems (e.g., no well defined specifications when
to signal what semaphore) were one of the reasons why Win32 doesn't
support the "three semaphore" primitive variants. It's simple when you
have only a single semaphore (e.g., signal it when the state of the
socket changes and give the client enough information about what's up
with the socket) but if you've got three of them with unclear signaling
behavior then the VM must guess which semaphore(s) to signal under which
condition. I don't know if Unix supports the three-semaphore variants
but if so it might be a very worthwhile exercise to disable it and see
if the problem goes away.

  - Andreas

More information about the Squeak-dev mailing list