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