(cc to Andreas and Ian since... well, am stuck! :-)

I am digging deeper and deeper here. Included below is the primitive as
on Win32:

int sqSocketReceiveDataAvailable(SocketPtr s)
{
  int sockState;

  if(!SocketValid(s)) return 0;
  DBG(s);
  sockState = SOCKETSTATE(s);
  return (sockState & SOCK_DATA_READABLE) /* e.g., do we have data? */
    && ((sockState & SOCK_PUBLIC_MASK) == Connected); /* and are we
still connected? */
}

...and in Unix:

int sqSocketReceiveDataAvailable(SocketPtr s)
{
  if (!socketValid(s))
    return -1;
  if (SOCKETSTATE(s) == Connected)
    {
      if (socketReadable(SOCKET(s)))
        return true;
      PSP(s)->pendingEvents|= READ_NOTIFY;
      aioHandle(SOCKET(s), dataHandler, PSP(s), AIO_RW);
    }
  return false;
}


I don't really now why this code looks like it does but I do wonder why
the unix version notifies the readSemaphore even if the socket is not
"socketReadable". I don't really know what aioHandle is/does but I
assume it will result in that "notify()" is called which in turn signals
the readSema. Obviously I am missing something fundamental here -
shouldn't the readSemaphore only be signalled if there is something to
read? On Win32 it seems to never signal the semaphore which also
seems.... funny. :-)

I include my original mail below.

regards, Göran
-----
We have some interesting problems under Linux. We have just
semi-verified it's a Linux - thing, Jonas here running on Win2k does not
have it - at least not when doing some simple tests.

We use Comanche with SocketStream and my problem is that this method:

waitForDataUntil: deadline
	"Wait up until the given deadline for data to arrive. Return true if
data arrives by the deadline, false if not."

	| dataArrived |
	[self isConnected & 
	 (dataArrived _ self primSocketReceiveDataAvailable: socketHandle) not
			"Connection end and final data can happen fast, so test in this
order"
		and: [Time millisecondClockValue < deadline]] whileTrue: [
			"self readSemaphore initSignals."
			self readSemaphore waitTimeoutMSecs: (deadline - Time
millisecondClockValue)].

	^ dataArrived

...seems to busyloop when I have a connected SocketStream waiting with
#nextLine. It eats up somewhere around 30-50% in the Process browser.
The UI process gets the rest - which is a bit weird in itself. On Win2k
it's the idle process that has about 100%, not the UI process. I just
assume that has something to do with the Linux port?

Anyway, after investigating a bit in the debugger we found that
#waitTimeoutMSecs: just flys by the "self wait" because there is an
excessive signal on the readSemaphore! Oops, seems not right. So the
#whileTrue: loop above is chugging along quite a lot...

And the signal gets there right after the
#primSocketReceiveDataAvailable: call above (which returns false btw).
Hmmph, why is that? As you can see I just threw in a hack above with
initSignals (now commented out) and that sure made it do a real wait.
But then it didn't wake up when data arrived!? So... what is going on
here?

regards, Gšran