[squeak-dev] Weird Socket Timeouts

Jon Hylands jon at huv.com
Fri Jun 26 11:24:03 UTC 2009


On Wed, 17 Jun 2009 14:45:04 -0400, Jon Hylands <jon at huv.com> wrote:

> The method took 7695 ms to execute, which seems a little strange. That's
> how long it took me to switch over to my client, and push the button to
> start sending packets, and then send 15 or 20 packets.
> 
> Why isn't it timing out after 31 ms?
> 
> The context of this whole thing is calling a variant of SocketStream >>
> #upTo: (one that doesn't wait for 100K of data). The packets are delimited
> with a CR (13).
> 
> Am I using this wrong, or is there a problem here?

So, I found out what the problem is, with some greatly appreciated help
from Göran (who wrote this version of SocketStream). There were two issues.

First issue was a bug in the Delay code, which has been recorded in Mantis
a couple times in the past, but not harvested.

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

Basically, the code to handle delays using an external semaphore was broken
in 3.9.

The second issue was something simpler - the class comment on SocketStream
says the following:

"SS can not be run unbuffered, since that seems unneeded. The option to
autoFlush is still available, with it set to true SocketStream (just like
OSS) will flush on its own on each nextPut:/nextPutAll:, otherwise flushing
it will have to be done manually but is done on close."

This is incorrect, as it turns out - what really happens when autoFlush is
set to true is that a flush is sent when the outgoing buffer is full,
which, as it turns out, is a 4KB buffer. So, this problem was actually on
the client side rather than the server side, and was easily fixed by using
nextPutAllFlush: instead of nextPutAll:

Thanks again to Göran for his help in this...

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      Jon at huv.com      http://www.huv.com/jon

  Project: Micro Raptor (Small Biped Velociraptor Robot)
           http://www.huv.com/blog



More information about the Squeak-dev mailing list