David, you should be aware that at 24000 baud flushing 64K of data  
takes awhile, also if flow control is involved then a flush could take
*forever*  I seem to remember many years ago seeing a flush/close  
sequence with a timeout that would truncate outbound data in Squeak for
those folks on slow dialup lines in their particular processing.

Also doing flush when the otherEndIsClosed is pointless. (well If I've  
gotten which end reader/writer pair is closed here the right way around  
for the discussion). Some platforms will allow the flush, then hang in  
the close as they attempt to really flush the last bits of data.

If you dig around in the source code a bit you'll find that some of  
these state transitions might not be discovered until you ask for the  
state, or as you point out you attempt some action.



On Mar 8, 2004, at 6:56 AM, C. David Shaffer wrote:
> Yes, you're right about that.  It makes me wonder why there is any  
> "guard" at all.  It just makes the SocketStream API more confusing  
> (throws an exception _if_ the connection is closed but the close  
> hasn't been detected yet).  You've pretty much convinced me that the  
> best solution is something like this (in SocketStream):
>
> flush
>    "Flush buffered data to socket.  Throws exception if data cannot be  
> sent."
>    self socket sendData: self outStream contents.
>    self resetOutStream
>
> close
>    "Attempts to #flush then closes socket.  Exceptions on flush or  
> close will be passed up but the close is always attempted."
>    [self flush] ensure: [self socket closeAndDestroy: 30]
>
> The usage pattern becomes:
>
> [socketStream close] on: NetworkError do: [:ex | "handle data  
> transmission error and/or close error if you like"].
>
> Then the various Socket method would have to be changed to throw the  
> various subclasses of NetworkError (filling in gaps where they exist).  
>  What do you think?
>
>>
>>  What I'd do is to handle the ConnectionTimedOut exception and the
>> other kind of exception differently if needed.
>>
> Yes, usually that would be appropriate.  What I'm proposing is having  
> "other kind of exception" be subclasses of NetworkError and leave  
> "self error: 'primitive failed'" for cases when a primitive fails due  
> to a non-sockets I/O related problem.
>
>>  I'm curious what kind of different actions we could take for
>> different type of errors.
>>
> I don't have an answer for that.  At the moment I simply need a  
> reasonable way to close a SocketStream which requires better error  
> support in Socket.  Maybe these other "actions" will come up as this  
> code evolves...?
>
> David
>
> --  
> C. David Shaffer
> http://www.cs.westminster.edu/~shaffer
> http://www.shaffer-consulting.com
>
>
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===