linux-kernel - Re: Rationale for paccept() sigset argument?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/