On Thu, 14 May 2009 10:15:37 +0200, Tobias Pape wrote:

> Hello John,
>
> Am 2009-05-13 um 21:11 schrieb John M McIntosh:
>
>> sounds like
>>
>> http://bugs.squeak.org/view.php?id=6581
>
>
> Unfortunately, this doesn’t seem to be the case.
> I do not experiences this particular symptoms:
> - In the case of 100% cpu usage, I’m not able to
>    VNC the image anymore.
> - If I’m already connected by VNC, moving the mouse does
>    not help.
> - It only happens in case of a HTTP PUT (i.e., pushing a new
>    mcz) that happens to be aborted by the use.
>
> Debugging such a process revealed the following:
> -	in WAKom>>process: the PUT-specific beaviour is called,
> 	i.e., the PUTData is tried to be retrieved
> (*in the meantime, the “other end” aborts the upload, thus closing
> 	the connection. The Socket is still connected on “out end”, though.)
> --	we are now in SocketStream>>next:
> ---	the End of the Stream is tested (#atEnd)
> --	because “our end” is still connected (I think) and we did not receive
> 	all data (because the connection was closed on the other end) we
> 	are not atEnd and there seems to be data available
> ---	thus we reach SocketStream>>receiveData
> ----	and Socket>>receiveDataTimeout:into:
> -----	and Socket>>receiveDataTimeout:into:startingAt:
> -----	there, the line
> !	self waitForDataFor: timeout ifClosed: [] ifTimeOut: [].
> 	occurs.
> -------Socket>>waitForDataFor:ifClosed:ifTimeOut:  determines that the
>   	Socket is closed (in contrary to #atEnd above), yet the given
> 	closedBlock is empty
> -----	thus, in and Socket>>receiveDataTimeout:into:startingAt: the
> primitve
> 	for reading data is called, where 0 is returned
> ---	therefore, in SocketStream>>receiveData the bytesRead is 0 and
> 	inStream is not altered
> --	we are now back in SocketStream>>next:
> 	atEnd, again, says that the stream is not at end and still connected.
> 	and since the inStream is unaltered, the second condition states that
> there
> 	would be data to read.
>
> I consider this a vicious circle.
>    The only cure I found  up until now was manually terminating these
> processes.
> Can somebody confirm this? I’d be grateful for any response.

The above (re. in contrary to #atEnd, etc) reminded me of this one,

- http://bugs.squeak.org/view.php?id=6951

perhaps some of the socket states/method comments are out of sync?

/Klaus

> So Long,
> 	-Tobias


-- 
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein