>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