"C. David Shaffer" <cdshaffer at acm.org> wrote:
>     1) Why would isOtherEndConnected be true but isConnected be false?  
> VM/socket plugin bug?  There are no documented semantics of isConnected 
> so I have no idea what it means.  isOtherEndConnected seems, for some 
> reason, exclusive of "isConnected not" (the status is checked with ==, 
> not a mask).  What are the semantics of this method?  I would think 
> Socket>>isOtherEndClosed would look more like ^self isClosed or: [insert 
> current code here].

isConnected means "is fully connected".  If you are only interested in
whether one side is still sending, then you need to ask a more specific
question.


>     3) even if you fix this problem, the "self error: 'whatever'" style 
> handling of primitive failures is not very useful.  There is a race 
> condition between the check of socket "closed" status and the sending of 
> data so the primitive could fail even if my test for an open socket 
> succeeded.  

Oh yes.  This is inherent in networking.  The BSD sockets API handles
this in just the way you expect, given the problem:


> The error: mechanism leaves me little to do defensively but 
> trap Error and check the text of the message or the context.


Well, BSD sockets uses -1 instead of Error, but it's the same idea.  You
have to just try your read() or write() and then check whether it
worked.


> This is a horrific abomination :-)  

Well, you know, the universe does not always have the most convenient
semantics.  :)  


IMHO, the best immediate "fix" is to be sure that proper exceptions are
used so that you don't have to catch the generic Error.  Other than
that, things look pretty good.  It may be possible to do better, but it
will take a whole new approach to sockets, not a tweak here and there. 
Networks are asynchronous, and you simply cannot rely on them to sit
still while you talk to them.

Also, this area horribly needs some documentation.

	1. The proper error handling approach should be described somewhere.
	
	2. The semantics of close should be documented.  At least on Unix, it
means "I promise not to send any more data".  It is perfectly allowed to
#close and then #receiveData: however.
	

	
-Lex