What is the contract of SocketStream>>#next:?

Assuming its 'shouldSignal' is true, if I say:

  mySocketStream next: 4

shouldn't I be guaranteed either 4 bytes of data, or an exception
(Timeout or ConnectionClosed)?  But, never less than 4 bytes of data,
right?

Over the last few weeks I have been running very heavy networking and
noticed several times "SocketStream>>#next: 4" returning me either an
empty Array or nil.  I've seen it more than once but can't reproduce
it.

Wouldn't that have to be a bug?

On Tue, Oct 7, 2014 at 3:42 PM, Nicolas Cellier
<[hidden email]> wrote:
> Since (String new readStream next: 4) answers an empty string, so at least
> this seem consistent with the rest...
> Some dialects have something like nextAvailable: 4 for this behavior and let
> next: 4 raise an exception, but not Squeak.

I get your point about consistency but isn't that impossible /
unusable for SocketStream?  Because there would be no way to discern
the difference between a Timeout and EOD (end of data).

I feel I should be able to write:

  header := mySocketStream next: 4

and not have to check the length of header before I access it.

Otherwise, please tell me what I should have to do if I get only 3
bytes of data back when I need and expect 4?  Treat it the same as a
Timeout?  Or loop try again?  Aren't those what SocketStream should be
doing for me?

> I feel I should be able to write:
>
>   header := mySocketStream next: 4
>
> and not have to check the length of header before I access it.

     Yeah, Squeak socket support is broken here (and a lot of other
places), I'd say.


-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

On Thu, Oct 9, 2014 at 3:19 AM, Craig Latta <[hidden email]> wrote:
>
>> I feel I should be able to write:
>>
>>   header := mySocketStream next: 4
>>
>> and not have to check the length of header before I access it.
>
>      Yeah, Squeak socket support is broken here (and a lot of other
> places), I'd say.

That might be overstating it.  I've only ever seen the issue under
very heavy load, so there might be a timing bug in the SocketStream
wrapper.

I was just trying to confirm the contract of this method with y'all so
I could proceed with scrutinizing it on that basis.

Chris> I feel I should be able to write:
Chris>
Chris> header := mySocketStream next: 4
Chris>
Chris> and not have to check the length of header before I access it.

Craig> Yeah, Squeak socket support is broken here (and a lot of other
Craig> places), I'd say.

Chris> That might be overstating it. I've only ever seen the issue
Chris> under very heavy load...

     Well, we disagree.


-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

On Thu, Oct 9, 2014 at 2:20 PM, Craig Latta <[hidden email]> wrote:
Maybe not, it might help if you elaborated some of the broken places,
I'm probably simply unaware of them.  My apps make very heavy use of
Squeak's Socket with no problems, but last month I upgraded Magma to
use the SocketStream wrapper and only then did I notice this issue
perhaps 2 or 3 times in the last month, and each time when a server
was processing thousands of requests per minute over TCP sockets.