[lkml]   [2008]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: sys_paccept: disable paccept() until API design is resolved
On Wednesday 17 September 2008 02:17:25 ext Ulrich Drepper, you wrote:
> It would unnecessarily require programs to be changed. I've explained
> that programs cannot efficiently use accept() and poll() when multiple
> threads are involved. This means in these situations you'll find a
> single thread handling only the accept() calls.

Hmm. In a multithreaded program, it makes a lot of sense to use blocking I/O
in general - not just blocking accept(). Of course, this assumes that there
is only one file descriptor to wait on at a time. This is not necessarily
true for I/O, nor is it for accept(). For instance, modern TCP servers should
have an IPv4 and an IPv6 socket to accept() from...

If the code path is such that only one file descriptor is being waited on at a
time, then using blocking I/O halves the number of syscalls, and thirds the
number of context switch between hardware packet reception, and userland data
deliver (3 to 1).

> > * The use of a sigset argument is not consistent with other I/O APIs
> > that can block on a single file descriptor (e.g., read(), recv(),
> > connect()).
> This is because none of the other interfaces had (so far) be revised.
> With this flawed argumentation you'd prevent any program ever to be made.


Then again... Why not recommend threaded programs to use sigwait() in a
dedicated task and give up on the asynchronous signal handlers completely?

Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2008-09-17 08:55    [W:0.043 / U:3.708 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site