> >> > 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_.
I'm now convinced that it doesn't.
> 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().
When I first ran into the interesting 'race' in queued sigio signals
(local close causing HUP then IN in 2.2) I freaked out and over-implemented
things in the io core I was playing with to deal with strangeness
in the signal queue. I was placing way too much faith in the validity
of the signals in the queue.
to really do a robust io core with queued rt sigio signals stephen and
andi have convinced me that you really, really have to treat the signals
as hints. You _have_ to keep local io core state of the descriptors
you care about and just treat the signal stream as hints to their state.
Thankfully in 2.3+ we can assume that a SIGHUP will be the last signal
queued for the lifetime of a descriptor so this becomes relatively
straight forward.
I guess my point is that we need not bend over backwards to put
lots of scary special code in the kernel to deal with stale/duplucate
signals in the stream. Any solid app using the signals is going to
have to deal with these cases anyway.
For what its worth, I have mixed feelings about the fd state inheritance
concept. It would indeed cut down on the number of syscalls in setting
up the fd, but at least in my case its so far off the radar that I'm
not concerned about it. The vast majority of the time phhttpd is spending
is dealing with networking stuff (checksumming, skb slab work, interrupt
stuff) and io event gunk (N signals / fd). I'm much more interested
in solving this with async sendfile() via listio (which I'm hacking on,
more news as it develops)
-- zach- 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 Feb 29 2000 - 21:00:20 EST