[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a36005b50809011748j75b1984ar844252a57f7e1d50@mail.gmail.com>
Date: Mon, 1 Sep 2008 17:48:44 -0700
From: "Ulrich Drepper" <drepper@...il.com>
To: "Michael Kerrisk" <mtk.manpages@...glemail.com>
Cc: "Ulrich Drepper" <drepper@...hat.com>,
"Davide Libenzi" <davidel@...ilserver.org>,
lkml <linux-kernel@...r.kernel.org>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Jakub Jelinek" <jakub@...hat.com>,
"Linus Torvalds" <torvalds@...ux-foundation.org>
Subject: Re: Rationale for paccept() sigset argument?
On Wed, Aug 20, 2008 at 9:50 AM, Michael Kerrisk
<mtk.manpages@...glemail.com> wrote:
> What is the rationale for the sigset argument of paccept()?
accept, like select/poll, is used often as a function to dealy
operation. Unlike read, recv, etc, which are handled using O_NONBLOCK
and select/poll. pselect/ppoll do not really have a sigset parameter
to handle signals in general. You use it to enable special handling
in case of blocking. Example: if you want to implement userlevel
context switching, you dedicate a signal to wake up any blocked
thread. Since accept falls more into the same category than poll,
this means the sigset parameter is justified. In theory we could add
it to all functions but there is no reason to do this without any
other reason to change the interface.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists