[BUG][FIX][FIX], was: (Re: Re: Flaw in SocketStream>>peek detected)

> Igor Stasenko wrote:
>>
>> My first attempt to fix it was also flawed. Thanks to Stephan for
>> pointing it out. (You can read our discussion here:
>> http://code.google.com/p/pharo/issues/detail?id=1813)
>>
>>
>> I hope this time its fixing it! :)
>
> From what I can tell, the changes are completely equivalent. Could you
> please write a test that illustrates what you think was wrong with the
> previous version? Attached are some tests that (I think) show that there's
> really no difference in these versions.
>

>
> #shouldSignal does NOT cover timeouts; timeouts are set separately, via
> #timeout:. If you want peek to wait forever you need to use, e.g.,
>
> | s|
> s:= (SocketStream openConnectionToHostNamed:  'google.com' port: 80) .
> s timeout: 0. "<- no timeouts please"
> s peek.
>
>
> Cheers,
>   - Andreas
>
>

> Andreas Raab wrote:
>> Igor Stasenko wrote:
>>> " the above should endup with timeout exception ,
>>> but following one should hang indefinitely"
>>
>> Absolutely not. Read the comment on shouldSignal:
>>
>>     "If shouldSignal is enabled the Socket Exceptions
>>     ConnectionClosed and ConnectionTimedOut"
>
> And I guess I should read more carefully, too :-) In any case, timeouts
> *are* handled via #timeout: and that makes good sense.

> Andreas Raab wrote:
>>
>> Andreas Raab wrote:
>>>
>>> Igor Stasenko wrote:
>>>>
>>>> " the above should endup with timeout exception ,
>>>> but following one should hang indefinitely"
>>>
>>> Absolutely not. Read the comment on shouldSignal:
>>>
>>>    "If shouldSignal is enabled the Socket Exceptions
>>>    ConnectionClosed and ConnectionTimedOut"
>>
>> And I guess I should read more carefully, too :-) In any case, timeouts
>> *are* handled via #timeout: and that makes good sense.
>
> (last response to my own post :-)
>
> And of course, the easy to do what you're trying to do is to change:
>
> shouldTimeout
>        ^timeout > 0 and:[shouldSignal]
>
> This would suppress all timeouts unless shouldSignal is true. BTW, I've
> never seen a case where I've been using a non-signaling socket stream. Does
> that case even exist?
>