On Fri, 12 Sep 2003, Andreas Raab wrote:

> done anything yet. Depending on the VM implementation this can cause severe
> trouble. You may want to check (on varying platforms) what the results of
> the following are:
> 					"Win32"
> a) client statusString.		 'connected'
> b) client getData.		 'Response'

where did 'c)' go?

> d) client statusString.		 'otherEndClosedButNotThisEnd'

Modulo #getData having vanished from Socket, in Unix we get

a) client statusString.		 'connected'
b) client getData.		 'Response'
c) client statusString.		 'connected'
d) client getData.		immediate error 'getData timeout'
e) client statusString.		 'otherEndClosedButNotThisEnd'

So what I might do is to try moving the check for otherEndClosed forward
into primSocketConnectionStatus to see if the image likes that better.  
(Although we don't know that this is the problem.  Also, the image really
should not rely on this.  Closing the other end of the connection does not
generate [unless you do some very unpleasant things with signals] any kind
of event in the still-connected peer, who is expected to deal with the
closure when the next _read_ operation _fails_.)  Note that this will make
Socket>>isConnected (and friends) measurably slower, but if that's the
price to pay, so be it...

(What are you hiding between 'b)' and 'd)'??? ;)

Regards,
Ian