The situation is even more strange with one particular sender of  
#waitForDataFor*, when attempting to receive data *after* the Socket had  
been disconnected on this side:

  | localhost serverSocket clientSocket worker |

  localhost := NetNameResolver localHostAddress.
"warning" Socket allInstancesDo: [:socket | socket destroy].
  serverSocket := Socket newTCP listenOn: 7680.
  clientSocket := Socket newTCP connectTo: localhost port: 7680.
  [clientSocket disconnect] on: Exception do: [:ex|].
  (Delay forMilliseconds: 125) wait.
  worker := [clientSocket receiveDataTimeout: 1
	into: (ByteArray new: 1) startingAt: 1]
		forkAt: Processor activeProcess priority.
  (Delay forMilliseconds: 125) wait.
  Transcript cr; show: serverSocket statusString, ' [server]';
	cr; show: clientSocket statusString, ' [client], dataAvailable: '
		, clientSocket dataAvailable storeString;
	cr; show: 'worker: ', worker browserPrintString; cr.
  [clientSocket destroy] on: Exception do: [:ex|].
  [serverSocket destroy] on: Exception do: [:ex|]

No exception: #receiveDataTimeout* passes empty blocks to #waitForDataFor*  
:(

- http://bugs.squeak.org/view.php?id=6951

On Mon, 25 Feb 2008 18:31:51 +0100, Igor Stasenko wrote:

> 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.
>