[Squeak 3.9] Socket waitForData won't wake up when data become available

Hello!

I was playing a little with the JDBC bridge, which is a TCP server on  
the loopback device, modifying it slightly. I discovered some strange  
behaviour on the way.

I'm controlling the tcp server by sending him commands through the  
loopback device. When you first connect to the server, it won't  
answer immediately, it rather waits for a set of commands first. So,  
I'm connecting to the server:

addr := NetNameResolver addressForName: 'localhost'.
socket := Socket newTCP connectTo: addr port: 1446.
stream := (SocketStream on: socket) timeout: 0

Now the two notice each, but nothing is sent in any direction except  
for the tcp handshake packages.

now, im installing my listener thread:

[stream next] fork

which blocks as expected, as I'm observing it in the process browser.

Now, i send the commands to the server, making it respond, through my  
private method sendThrough. the sent commands provably arrive at the  
server and do make it respond (the response actually arrives in the  
socketStreams inbuffer!)

'one' sendThrough: stream. 'two' sendThrough: stream . 'three'  
sendThrough: stream.

inspecting the stream reveals that the data has arrived and landed in  
the buffer, but a look into the process browser shows that the frozen  
process waiting for data won't wake up!

even if you alter the example by using

[socket waitForData] fork

as reading thread, it won't wake up.

It doesn't help either to set the SocketStream with a timeout greater  
than 0. if i do that, it times out after 45 seconds, eventhough data  
are available.

Now, this is relatively annoying to me. Of course I could restructure  
the code to only read the socket when there are most probably data to  
be received; but that would be less reliable and certainly uglier  
than my reading process.

so, does anyone have a clue what I'm doing wrong?

thanks in advance,

Niko

On Tue, 12 Jun 2007 01:00:45 +0200, Niko Schwarz <[hidden email]>
wrote:

> Now, this is relatively annoying to me. Of course I could restructure  
> the code to only read the socket when there are most probably data to  
> be received; but that would be less reliable and certainly uglier  
> than my reading process.

Try setting the buffered flag in the socket stream to false.

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      [hidden email]      http://www.huv.com/jon

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

Hi!

Niko Schwarz <[hidden email]> wrote:
Ok, could this simply be due to Process scheduling? Is this fork getting
starved?

Because reading my code (I wrote this version of SocketStream) I can't
for my life figure out how it could block AND get data into the inbuffer
instvar.

Btw, I noticed in 3.8.1 the #buffered: and #buffered methods. They do
not belong there - I have no idea why they are there or why they are
empty. In FastSocketStream (on SM), which is the original implementation
of this newish SocketStream class there are no such methods.

regards, Göran

[hidden email] wrote:

> Btw, I noticed in 3.8.1 the #buffered: and #buffered methods. They do
> not belong there - I have no idea why they are there or why they are
> empty. In FastSocketStream (on SM), which is the original implementation
> of this newish SocketStream class there are no such methods.

Hmm, some artifact from switching to FastSocketStream in the 3.8.1
update stream? Can you check if there are other changes that shouldn't
be there?

Michael

Hi!

Michael Rueger <[hidden email]> wrote:
Yeah, I can look it over. And to Niko: setting bufferSize: 0 seems...
he, I have no idea how that could even begin to work. :)

Btw, note that I am looking in 3.8.1, not 3.9. Perhaps SocketStream has
been changed in 3.9, but I doubt it.

regards, Göran

Michael Rueger <[hidden email]> wrote:
And also - by "empty" I mean *empty* as in brokenly-weird-empty - not
just-an-empty-implementation-of-a-method.
I don't even get a signature in the code pane! And no implementors of it
either.

regards, Göran

On Tue, 12 Jun 2007 10:32:40 +0200 , [hidden email] wrote:

> And also - by "empty" I mean *empty* as in brokenly-weird-empty - not
> just-an-empty-implementation-of-a-method.
> I don't even get a signature in the code pane! And no implementors of it
> either.

My image is 3.8, #6665. The instance variable 'buffered' is actually used:

checkFlush
        self buffered
                ifTrue: [self autoFlush
                        ifTrue: [self outStream position > self bufferSize
                                ifTrue: [self flush]]]
                ifFalse: [self flush]

initialize
        buffered := true.
        autoFlush := true.
        binary := false

The two methods #buffered and #buffered: are standard get and set methods.

Maybe your image is corrupt?

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      [hidden email]      http://www.huv.com/jon

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

Jon Hylands wrote:
> On Tue, 12 Jun 2007 10:32:40 +0200 , [hidden email] wrote:
>
>> And also - by "empty" I mean *empty* as in brokenly-weird-empty - not
>> just-an-empty-implementation-of-a-method.
>> I don't even get a signature in the code pane! And no implementors of it
>> either.
>
> My image is 3.8, #6665. The instance variable 'buffered' is actually used:

That explains it. that is 3.8, not 3.8.1. Only the latter includes the
FastSocketStream implementation renamed as SocketStream. Not only fast
but also less buggy than my original implementation.
You should be able to simply run updates to get to 3.8.1.

Michael