>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.
>
> Regards,
>
> Richard....
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.
>
>-
>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