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 17:10:02 +0200 Message-ID: <834kjd7yk5.fsf@gnu.org> References: <20210116184947.2105.45267@vcs0.savannah.gnu.org> <20210116184949.3C17C211A5@vcs0.savannah.gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32392"; mail-complaints-to="usenet@ciao.gmane.io" Cc: phst@google.com, emacs-devel@gnu.org To: p.stephani2@gmail.com (Philipp Stephani) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 19 16:11:03 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 1l1set-0008Ju-5e for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Jan 2021 16:11:03 +0100 Original-Received: from localhost ([::1]:47490 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l1ses-0006rl-41 for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Jan 2021 10:11:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52586) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l1sdo-00060l-8M for emacs-devel@gnu.org; Tue, 19 Jan 2021 10:09:56 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53613) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l1sdn-0000rC-VE; Tue, 19 Jan 2021 10:09:55 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3106 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l1sdn-0004w6-1M; Tue, 19 Jan 2021 10:09:55 -0500 In-Reply-To: <20210116184949.3C17C211A5@vcs0.savannah.gnu.org> (p.stephani2@gmail.com) 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:263171 Archived-At: > Date: Sat, 16 Jan 2021 13:49:49 -0500 (EST) > From: p.stephani2@gmail.com (Philipp Stephani) > > branch: scratch/sigchld-fd > commit 8f0ce42d3eb9b212424a4a25a376287ffc94a73e > Author: Philipp Stephani > Commit: Philipp Stephani > > Fix deadlock when receiving SIGCHLD during 'pselect'. > > If we receive and handle a SIGCHLD signal for a process while waiting > for that process, 'pselect' might never return. Instead, we have to > explicitly 'pselect' that the process status has changed. We do this > by writing to a pipe in the SIGCHLD handler and having > 'wait_reading_process_output' select on it. > > * src/process.c (child_signal_init): New helper function to create a > pipe for SIGCHLD notifications. > (child_signal_read, child_signal_notify): New helper functions to > read from/write to the child signal pipe. > (create_process): Initialize the child signal pipe on first use. > (handle_child_signal): Notify waiters that a process status has > changed. > (wait_reading_process_output): Make sure that we also catch > SIGCHLD/process status changes. > > * test/src/process-tests.el > (process-tests/fd-setsize-no-crash/make-process): Remove workaround, > which is no longer needed. Philipp, can you please elaborate about this changeset (which was in the meantime merged with master)? The comments you added mention some kind of deadlock, but don't describe what kind and in which situations it could happen, and without that it's hard to understand what problem(s) it tries to solve. 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. 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. Thanks.