Messages in this thread | | | From | "Anthony Barbachan" <> | Subject | Re: Thread implementations... | Date | Sat, 20 Jun 1998 21:36:47 -0400 |
| |
-----Original Message----- From: Richard Gooch <Richard.Gooch@atnf.CSIRO.AU> To: Anthony Barbachan <barbacha@trill.cis.fordham.edu> Cc: David S. Miller <davem@dm.cobaltmicro.com>; dgaudet-list-linux-kernel@arctic.org <dgaudet-list-linux-kernel@arctic.org>; linux-kernel@vger.rutgers.edu <linux-kernel@vger.rutgers.edu> Date: Saturday, June 20, 1998 5:03 AM Subject: Re: Thread implementations...
>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
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.
>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.
> Regards, > > Richard.... > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.rutgers.edu >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |