Re: [PATCH] async poll for 2.5

[John Gardiner Myers <jgmyers@netscape.com>]

[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]

Davide Libenzi wrote:

>I don't want this to become the latest pro/against threads but if your
>processing thread block for a long time you should consider handling the
>blocking condition asynchronously. If your procesing thread blocks, your
>application model should very likely be redesigned, or you just go with
>threads ( and you do not need any multiplex interface ).
>
Rewriting the code to handle the blocking condition asynchronously can 
be inordinately expensive and time consuming.  This is particularly true 
when using third party code (such as the system DNS resolver) which only 
has blocking interfaces.

A much more cost effective and timely methodology is to only 
asynchronously code the most important conditions, leaving threads to 
handle the rest.

>Your assumption is wrong, the registration is done as soon as the fd
>"born" ( socket() or accept() for example ) and is typically removed when
>it dies.
>
Nonetheless, the requirement for user space to test the condition after 
the registration, not before, is subtle.  A program which does these in 
the wrong order is still likely to pass QA and will fail in production 
in a way that will be difficult to diagnose.  There is no rational 
reason for the kernel to not test the condition upon registration.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3537 bytes --]