Hello!
> Hopefully there isn't a race condition: if you read 1400 bytes and a
> packet arrives _during_ the read, a signal must be queued.
Signal _is_ really queued, because current linux floods signals brainlessly
every time when something arrives. But it would be better if linux
did not make this and avoided lots of useless work during bulk receive,
not comparable with poor plain would-be redundant read() returning EAGAIN. 8)
Actually, long-long ago it was documented as big difference between sunos-5
and sunos-4: solaris-2.x sends signals (not rt that time) only when something
is added to _empty_ queue and does not send spurious signals, saving time
for real work.
I am sorry, but apps cannot expect that they will be awaken by a signal
before they received from kernel notification that queue is empty,
i.e. EAGAIN or no event in poll().
Signal queueing makes this issue much more important, because events
are not merged and signal overhead f.e. when receiving on ethernet
becomes non-trivial.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:20 EST