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