From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753467AbYIHNd4 (ORCPT ); Mon, 8 Sep 2008 09:33:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752154AbYIHNds (ORCPT ); Mon, 8 Sep 2008 09:33:48 -0400 Received: from py-out-1112.google.com ([64.233.166.179]:39644 "EHLO py-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751719AbYIHNdr (ORCPT ); Mon, 8 Sep 2008 09:33:47 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=CqMjKSkNify+3afftesvvIG4WJhRBDGS7VVV1B4VCLV2AxNRWQoP6ZuioRqNX22l38 hP8IOA4DzaOrVEDT1IzIDuenT34NFDEAFcPUsoF7wTWeqHnGmReVn3MsO0d4/ERUTLVr mrEVZOWbissnqxyB7YbqPbV5TLzC0pM0ZZ6Xk= Message-ID: Date: Mon, 8 Sep 2008 15:33:46 +0200 From: "Michael Kerrisk" Reply-To: mtk.manpages@gmail.com To: "Ulrich Drepper" Subject: Re: Rationale for paccept() sigset argument? Cc: "Michael Kerrisk" , "Davide Libenzi" , lkml , "Andrew Morton" , "Jakub Jelinek" , "Linus Torvalds" In-Reply-To: <48BCF211.3050809@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48AC4B44.2010606@gmail.com> <48BCF211.3050809@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ulrich -- ping! ---------- Forwarded message ---------- From: Michael Kerrisk Date: Sep 2, 2008 9:58 AM Subject: Re: Rationale for paccept() sigset argument? To: Ulrich Drepper Cc: Michael Kerrisk , Ulrich Drepper , Davide Libenzi , lkml , Andrew Morton , Jakub Jelinek , Linus Torvalds Ulrich Drepper wrote: > On Wed, Aug 20, 2008 at 9:50 AM, Michael Kerrisk > 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. > Ulrich, you snipped a relevant piece of my earlier message: [[ > * It seems to me that any case where we might want to use paccept() could be > equivalently dealt with using the existing pselect()/ppoll()/epoll_pwait() > followed by a conventional accept() if the listening file descriptor > indicates as ready. ]] So I'll rephrase: what use case does the sigset argument of paccept() allow us to handle that couldn't equally have been handled by pselect()/ppoll()/epoll_pwait() + traditional accept()? Cheers, Michael