kuznet@ms2.inr.ac.ru wrote:
> > :-) Fair enough; I hope you can see that there is a way to reduce the
> > over-signalling without breaking applications.
>
> ? I do not understand you. There are still no applications to break,
> SVR4 does not oversignal.
> It was you who propose to promote status of
> oversignaling from a linux bug to required feature.
I'd like to avoid oversignalling in general of course. Event merging
etc. is always good.
The desirable feature, which is so rare that I don't think it counts as
oversignalling but it is a race, is this:
If read(fd, buf, size) returns < size bytes, there is no need to follow
it with a _second_ read() to ensure the buffer is empty.
To put it another way, if the buffer is not empty after a read(), you
guarantee that the read() returned a full buffer or an error condition.
It is simply an ordering constraint.
The effect, if any, is very small because it only affects that short
window between the end of the read loop and the point where you set the
"send me a signal if new data arrives" flag on the socket. I.e., you
just order those correctly.
It should be a win because of this:
Having to do a second read() which returns EAGAIN is a cost you always
have to incur. Whereas the possibility of an extra signal (above what
you'd get anyway) is a rare extra event from rt_sigtimedwait.
(The events aren't rare, but the additional occurrence due to ensuring
the ordering should be tiny).
enjoy,
-- Jamie
-
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 : Wed Mar 15 2000 - 21:00:14 EST