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.

So Long,
	-Tobias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: Signierter Teil der Nachricht
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090514/d80663ea/PGP.pgp