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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:58 EST