Squeakers:

In 3.6 SocketStream>>flush looks like this:

flush
    self isOtherEndConnected
        ifTrue: [self socket sendData: self outStream contents].
    self resetOutStream

Under the R.H. Linux VM (supplied by Ian) I'm seeing several cases where 
isOtherEndConnected is true but isConnected is false.  The fact is that 
the "other end" is long gone and couldn't possibly be connected.  In 
those cases the sendData: throws an error indicating that a primitive 
failed.  I remember a conversation about this previously but I can't 
find it in the archives.  Two questions and one complaint:

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

    2) Would changing the test, in SocketStream, to "self isConnected & 
self isOtherEndConnected" be a workaround for a bug (causing the 
condition above) or would be a "fix" of the flush method or just a 
temporary hack to get around 1.

    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.  The error: mechanism leaves me little to do defensively but 
trap Error and check the text of the message or the context.  This is a 
horrific abomination :-)  Worse, the image is replete with examples of 
#error: sends which really need to be more useful exceptions even in 
cases where the "error" has an obvious need for potentially being 
handled.  Now, hold all your "go ahead and fix it comments" since I know 
that line well.  I'll be happy to fix the ones that I can identify but 
what I want to know is if there is a consensus that this is a problem.  
If so, is one of the various harvesting efforts trying to correct it 
(KCP maybe?  sorry to bring you into this Stephane).  BTW, this isn't 
Smalltalk specific, every java shop I've ever visited had tons of "throw 
new Exception("Something when wrong") kinds of things.



David

-- 
C. David Shaffer
http://www.cs.westminster.edu/~shaffer
http://www.shaffer-consulting.com