Re: Thread implementations...
Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Sat, 20 Jun 1998 17:33:36 +1000
Anthony Barbachan writes:
>
> -----Original Message-----
> From: Richard Gooch <Richard.Gooch@atnf.CSIRO.AU>
> To: David S. Miller <davem@dm.cobaltmicro.com>
> Cc: dgaudet-list-linux-kernel@arctic.org
> <dgaudet-list-linux-kernel@arctic.org>; linux-kernel@vger.rutgers.edu
> <linux-kernel@vger.rutgers.edu>
> Date: Friday, June 19, 1998 6:50 AM
> Subject: Re: Thread implementations...
>
>
> >David S. Miller writes:
> >> Date: Thu, 18 Jun 1998 11:37:28 -0700 (PDT)
> >> From: Dean Gaudet <dgaudet-list-linux-kernel@arctic.org>
> >[...]
> >> Unix multiplexing facilities -- select and poll -- are wake-all
> >> primitives. When something happens, everything waiting is awakened
> >> and immediately starts fighting for something to do. What a waste.
> >> They make a lot of sense for processes though. On NT completion
> >> ports provide wake-one semantics... which are perfect for threads.
> >>
> >> Yes, this does in fact suck. However, the path to go down is not to
> >> expect the way select/poll work to change, rather look at other
> >> existing facilities or invent new ones which solve this problem.
> >> Too much user code exists which depends upon the wake-all semantics,
> >> so the only person to blame is whoever designed the behaviors of these
> >> unix operations to begin with ;-)
> >
> >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
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...
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu