From: Jeff King Date: Tue, 02 Apr 2013 05:26:30 GMT Subject: Re: [PATCH 1/4] run-command: add new check_command helper Message-ID: <20130402052630.GB22089@sigill.intra.peff.net> In-Reply-To: On Mon, Apr 01, 2013 at 11:22:36PM -0600, Felipe Contreras wrote: > On Mon, Apr 1, 2013 at 11:14 PM, Jeff King wrote: > > On Mon, Apr 01, 2013 at 11:11:20PM -0600, Felipe Contreras wrote: > > > >> > But if we know from reading waitpid(3) that waitpid should only fail due > >> > to EINTR, or due to bogus arguments (e.g., a pid that does not exist or > >> > has already been reaped), then maybe something like this makes sense: > >> > > >> > while ((waiting = waitpid(pid, &status, 0)) < 0 && errno == EINTR) > >> > ; /* nothing */ > >> > >> But we don't want to wait synchronously here, we just want to ping. > > > > Yeah, sorry, I forgot the WNOHANG there. > > It still can potentially stay in a loop for some cycles. That should be OK; it's the same loop we use in wait_or_whine (and that is in fact how I managed to get the WNOHANG wrong, as I copied the loop from there but forgot to update the flag variable). A few cycles is OK, as it is really about handling a simultaneous signal; it should be rare that we loop at all, and even rarer to loop more than a single time. On Linux, I don't think we will ever get EINTR at all, according to the manpage; however, POSIX seems to allow EINTR even with WNOHANG. -Peff