Re: accept() improvements for rt signals

From: Stephen C. Tweedie (sct@redhat.com)
Date: Tue Feb 22 2000 - 07:41:00 EST


Hi,

On Mon, 21 Feb 2000 09:02:10 -0800, Dan Kegel <dank@alumni.caltech.edu>
said:

>> > Also, what if there's more than one queue (e.g. a listening
>> > socket with one owner/signum, and connected sockets with a
>> > different owner/signum)? Which queue do you empty? Better
>> > to use an atomic accept()+F_SETFAST combo that generates an
>> > 'fd created' signal, then there's no need to empty any queue.
>>
>> Yep. I agree.

> OK, cool. Don't know if we will get this race closed soon, but
> it's nice that somebody else besides me now agrees it exists :-)

I've always agreed that it exists, but nobody has demonstrated so far
that it _matters_.

Do you get these stale, unexpected siginfo events often enough that the
unnecessary read()s it results in becomes a serious performance problem?
If not, then the race simply doesn't matter --- you treat the siginfos
as advisory, and you perform a read() if you get a POLLIN siginfo, but
you don't worry overly if you get a siginfo for a fd which is no longer
in use or if you get no data on the read().

>> Is there any expectations that si_band will be used in 2.2?

> I think there's a patch you can apply.

There is.

--Stephen

-
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 Feb 23 2000 - 21:00:30 EST