Bump... Any help or suggestions out there for this?
On Wed, 17 Jun 2009 14:45:04 -0400, Jon Hylands jon@huv.com wrote:
Hi everyone,
So, I've moved up to Squeak 3.10.2 (#7179). I'm still running the same VM (3.10.6) on Windows XP.
I'm running into a weird delay issue with the new SocketStream class. I've narrowed it down to Semaphore >> #waitTimeoutMSecs:
Here's the scenario: The client is sending 220 byte packets to the server, about one every 50 ms. The server is basically buffering those, until the 4K buffer fills up. Looking at the stack, and with some logging, I can see that it is pausing in Semaphore >> #waitTimeoutMSecs:. I hacked the caller (Socket >> #waitForDataFor:ifClosed:ifTimedOut:) to pass something less than 50 ms as the argument. In this case it passes 31.
I've added a couple log messages to the beginning and end of that method:
17154400 - entering Semaphore >> waitTimeoutMSecs: 31 17162095 - exiting Semaphore >> waitTimeoutMSecs:...
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?
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog