Re: Thread implementations...
Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Sun, 21 Jun 1998 13:40:57 +1000
Anthony Barbachan writes:
> >> From: Richard Gooch <Richard.Gooch@atnf.CSIRO.AU>
> >> >On the other hand you could say that the UNIX semantics are fine and
> >> >are quite scalable, provided you use them sensibly. Some of these
> >> >"problems" are due to applications not being properly thought out in
> >> >the first place. If for example you have N threads each polling a
> >> >chunk of FDs, things can run well, provided you don't have *each*
> >> >thread polling *all* FDs. Of course, you want to use poll(2) rather
> >> >than select(2), but other than that the point stands.
> >>
> >> The ideal might be select functions with an extra parameter in which we
> can
> >> pass a function's address which would then be called automatically, with
> an
> >> active file descriptor as a parameter, when it is ready.
> >
> >What are you trying to solve here? The kernel scan of all FDs to check
> >for activity is still needed, unless you have something radically
>
> Why is the kernel scan needed? Activity on a file handle doesn't just
> magically appear. The kernel had to make it active in the first place.
The kernel scan is in the implementation of select(2) and
poll(2). Read fs/select.c to see how it's done. For each FD in your
array, the kernel has to check for activity. If you specify a timeout
and there is no activity yet, the kernel puts your process to sleep
and when activity does finally happen, this scan is performed *again*.
> >different in mind (aka. AIO). And it is this kernel scan that chews up
> >lots of time.
> >There is another problem, and that is that application scan for which
> >FDs the kernel said are active: currently the application has to scan
> >all those FDs. There is a way around this too, but there are other
> >things to sort out first...
>
> This is the one I was thinking about.
That is easily solved by implementing poll2(2), which I did last year
(not submitted because there is not much point until other things are
optimised). Hopefully sometime during 2.3 I'll have time to get back
to this.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu