From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: scratch/sigchld-fd 8f0ce42 1/2: Fix deadlock when receiving SIGCHLD during 'pselect'. Date: Tue, 19 Jan 2021 21:14:16 +0200 Message-ID: <83turc7n93.fsf@gnu.org> References: <20210116184947.2105.45267@vcs0.savannah.gnu.org> <20210116184949.3C17C211A5@vcs0.savannah.gnu.org> <834kjd7yk5.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7467"; mail-complaints-to="usenet@ciao.gmane.io" Cc: phst@google.com, emacs-devel@gnu.org To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 19 21:10:04 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l1xKG-0001qX-9l for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Jan 2021 21:10:04 +0100 Original-Received: from localhost ([::1]:56972 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l1xKF-0000yy-9x for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Jan 2021 15:10:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34326) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l1wS8-0001NZ-UN for emacs-devel@gnu.org; Tue, 19 Jan 2021 14:14:08 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59167) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l1wS8-0006si-Lk; Tue, 19 Jan 2021 14:14:08 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2208 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l1wS7-0007Op-V8; Tue, 19 Jan 2021 14:14:08 -0500 In-Reply-To: (message from Philipp Stephani on Tue, 19 Jan 2021 19:21:39 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:263181 Archived-At: > From: Philipp Stephani > Date: Tue, 19 Jan 2021 19:21:39 +0100 > Cc: Emacs developers , Philipp Stephani > > In general, pselect is supposed to return with EINTR when SIGCHLD > > happoens while we are inside the call to pselect, and EINTR seems to > > be already handled by wait_reading_process_output. So I wonder why we > > need that additional "self-pipe" to be watched by pselect. > > Yes, I'm wondering about that as well, but it's definitely the > behavior I see. Before commiting to master, I ran the test > process-tests/fd-setsize-no-crash/make-process multiple times with and > without the commit, and the outcome was clear: without the commit > accept-process-output would frequently hang, with the commit it never > hangs. > This is pure speculation, but I could imagine multiple things going on: > - Maybe there's no guarantee that pselect actually returns EINTR on SIGCHLD. > - Maybe EINTR is returned too early, before the signal handler got the > chance to update the process status. I'd be happier if we had some direct evidence to these effects. I'd also be surprised to hear that pselect doesn't return with EINTR when SIGCHLD comes in. It is more likely that SIGCHLD is delivered before we call pselect, but if that is the case, we should be able to reliably detect that, I think. > > In addition, AFAIU this pipe should not be needed on MS-Windows, where > > the pselect emulation waits on the sub-process handles together with > > the other file descriptors, and so gets awakened when a process exits > > or dies. But again, without knowing the exact situations against > > which this changeset tries to protect, it is hard to make a decision. > > It's definitely not needed on Windows, which has a superior mechanism > anyway (process handles are waitable objects in Windows). I opted to > create the additional pipe on Windows as well - the costs should be > small, and it keeps the code more consistent between the operating > systems. The thing is, on Windows we can only wait on up to 64 handles (unless we complicate the code with multilevel wait, that is), so every unnecessary descriptor we need to wait on means we can support fewer simultaneous subprocesses. We are already limited to just 32 subprocesses, which is quite low a number.