Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752116AbYLMSj1 (ORCPT ); Sat, 13 Dec 2008 13:39:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751077AbYLMSjU (ORCPT ); Sat, 13 Dec 2008 13:39:20 -0500 Received: from x35.xmailserver.org ([64.71.152.41]:45419 "EHLO x35.xmailserver.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750885AbYLMSjT (ORCPT ); Sat, 13 Dec 2008 13:39:19 -0500 X-AuthUser: davidel@xmailserver.org Date: Sat, 13 Dec 2008 10:39:13 -0800 (PST) From: Davide Libenzi X-X-Sender: davide@alien.or.mcafeemobile.com To: Scott James Remnant cc: Casey Dahlin , Linux Kernel Subject: Re: [RFC PATCH] waitfd: file descriptor to wait on child processes In-Reply-To: <1229157789.6128.0.camel@warcraft> Message-ID: References: <493EA441.1070706@redhat.com> <1229124491.12618.5.camel@warcraft> <1229157789.6128.0.camel@warcraft> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1383 Lines: 39 On Sat, 13 Dec 2008, Scott James Remnant wrote: > On Fri, 2008-12-12 at 20:29 -0800, Davide Libenzi wrote: > > > And how about this? > > > > sfd = signalfd(SIGCHLD); > > > > for (;;) { > > poll(sfd, POLLIN); > > while ((pid = waitpid(0, &status, WNOHANG)) != -1) > > process_child_death(pid); > > } > > > At this point, why have signalfd()'s read() return siginfo_t at all? > > You have to discard the entire information since it's only ever the > first signal that matched, all subsequent ones are thrown away. Signalfd is a wakeup gate available to the poll/select/epoll subsystems. Signals that are queued inside the kernel, get de-queueing behavior, while signals that are overlapping, get overlapping behavior. The code above enable you to wait for signals inside a poll/select/epoll dispatch loop, and get all the info waitpid() can return to you - w/out missing anything. In a real app case, you're probably waiting for more than simple SIGCHLD, so you likely will have one (or more) read(2) of the signalfd to find out which signal you got, and do the waitpid(WNOHANG) loop in case of SIGCHLD. - Davide -- 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/