[squeak-dev] Socket>>#waitForDataFor: and #primSocketReceiveDataAvailable

> I'm trying to provoke the Exceptions which Socket>>#waitForDataFor: would
>  signal on failure (and test that it does so), to no avail (no, the .image
>  isn't locked and the process doesn't hang).
>
>  The below runs in both the Squeak 3.9,3.8 final .images with both the
>  3.10.2,3.10.6 VMs on win32; the worker process always terminates without
>  an exception.
>
>  The implementation of #waitForDataFor:
>  (#waitForDataFor:ifClosed:ifTimedOut:) looks like #dataAvailable returns
>  true but there cannot be any data since nothing was ever sent. *but* after
>  closing the client side, the other side's #dataAvailable
>  (#primSocketReceiveDataAvailable) returns true ...
>
>  Any hint(s) on what's going on (or wrong) will be recognized with
>  gratitude.
>
>  /Klaus
>
>   | localhost serverSocket sessionSocket clientSocket worker |
>
>   localhost := NetNameResolver localHostAddress.
>  "warning:" Socket allInstancesDo: [:socket | socket destroy].
>   serverSocket := Socket newTCP listenOn: 7680 backlogSize: 1.
>   clientSocket := Socket newTCP connectNonBlockingTo: localhost port: 7680.
>   sessionSocket := serverSocket waitForAcceptFor: 1.
>   worker := [sessionSocket waitForDataFor: 1] fork.
>   Processor yield.
>   Transcript cr; show: serverSocket statusString, ' [server]';
>         cr; show: clientSocket statusString, ' [client]';
>         cr; show: sessionSocket statusString, ' [session], dataAvailable: '
>                 , sessionSocket dataAvailable storeString;
>         cr; show: 'worker: ', worker browserPrintString.
>   [clientSocket close] on: Exception do: [:ex|].
>   Processor yield.
>   Transcript cr; show: serverSocket statusString, ' [server]';
>         cr; show: clientSocket statusString, ' [client]';
>         cr; show: sessionSocket statusString, ' [session], dataAvailable: '
>                 , sessionSocket dataAvailable storeString;
>         cr; show: 'worker: ', worker browserPrintString; cr.
>   [sessionSocket destroy] on: Exception do: [:ex|].
>   [clientSocket destroy] on: Exception do: [:ex|].
>   [serverSocket destroy] on: Exception do: [:ex|]
>
>
>

> On 25/02/2008, Klaus D. Witzel wrote:
>> I'm trying to provoke the Exceptions which Socket>>#waitForDataFor:  
>> would
>>  signal on failure (and test that it does so), to no avail (no, the  
>> .image
>>  isn't locked and the process doesn't hang).
>>
>>  The below runs in both the Squeak 3.9,3.8 final .images with both the
>>  3.10.2,3.10.6 VMs on win32; the worker process always terminates  
>> without
>>  an exception.
>>
>>  The implementation of #waitForDataFor:
>>  (#waitForDataFor:ifClosed:ifTimedOut:) looks like #dataAvailable  
>> returns
>>  true but there cannot be any data since nothing was ever sent. *but*  
>> after
>>  closing the client side, the other side's #dataAvailable
>>  (#primSocketReceiveDataAvailable) returns true ...
>>
>>  Any hint(s) on what's going on (or wrong) will be recognized with
>>  gratitude.
>>
>>  /Klaus
>>
>>   | localhost serverSocket sessionSocket clientSocket worker |
>>
>>   localhost := NetNameResolver localHostAddress.
>>  "warning:" Socket allInstancesDo: [:socket | socket destroy].
>>   serverSocket := Socket newTCP listenOn: 7680 backlogSize: 1.
>>   clientSocket := Socket newTCP connectNonBlockingTo: localhost port:  
>> 7680.
>>   sessionSocket := serverSocket waitForAcceptFor: 1.
>>   worker := [sessionSocket waitForDataFor: 1] fork.
>>   Processor yield.
>>   Transcript cr; show: serverSocket statusString, ' [server]';
>>         cr; show: clientSocket statusString, ' [client]';
>>         cr; show: sessionSocket statusString, ' [session],  
>> dataAvailable: '
>>                 , sessionSocket dataAvailable storeString;
>>         cr; show: 'worker: ', worker browserPrintString.
>>   [clientSocket close] on: Exception do: [:ex|].
>>   Processor yield.
>>   Transcript cr; show: serverSocket statusString, ' [server]';
>>         cr; show: clientSocket statusString, ' [client]';
>>         cr; show: sessionSocket statusString, ' [session],  
>> dataAvailable: '
>>                 , sessionSocket dataAvailable storeString;
>>         cr; show: 'worker: ', worker browserPrintString; cr.
>>   [sessionSocket destroy] on: Exception do: [:ex|].
>>   [clientSocket destroy] on: Exception do: [:ex|].
>>   [serverSocket destroy] on: Exception do: [:ex|]
>>
>>
>>
>
>

> On Mon, 25 Feb 2008 16:24:43 +0100, Igor Stasenko wrote:
>
>  > I think it was done intentionally,
>  > when socket closed , it signals that data available, to awake process
>  > which waiting for data. Then, when process tries to read it, it
>  > returns 0 bytes.
>
>
> Nothing speaks against such behavior except the method's comment "Wait for
>  the given nr of seconds for data to arrive. Signal a time out or
>  connection close exception if either happens before data becomes
>  available."
>
>
>  > I think it's same as with socket's read() function.
>  > If remote side closed gracefully, a blocking read() function returns
>  > with 0, indicating that there 0 bytes read, and connection is closed.
>
>
> So senders of #waitForDataFor: cannot know about closed connections (even
>  if the comment says the opposite) and *must* do at least #receiveSomeData
>  because #waitForDataFor: can't handle all the possible situations?
>

> On 25/02/2008, Klaus D. Witzel wrote:
>> On Mon, 25 Feb 2008 16:24:43 +0100, Igor Stasenko wrote:
>>
>>  > I think it was done intentionally,
>>  > when socket closed , it signals that data available, to awake process
>>  > which waiting for data. Then, when process tries to read it, it
>>  > returns 0 bytes.
>>
>>
>> Nothing speaks against such behavior except the method's comment "Wait  
>> for
>>  the given nr of seconds for data to arrive. Signal a time out or
>>  connection close exception if either happens before data becomes
>>  available."
>>
>>
>>  > I think it's same as with socket's read() function.
>>  > If remote side closed gracefully, a blocking read() function returns
>>  > with 0, indicating that there 0 bytes read, and connection is closed.
>>
>>
>> So senders of #waitForDataFor: cannot know about closed connections  
>> (even
>>  if the comment says the opposite) and *must* do at least  
>> #receiveSomeData
>>  because #waitForDataFor: can't handle all the possible situations?
>>
>
> I really don't know how primitives handling this. So it's only my
> guess why data signaled when there is no data at all.
>