From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.bugs Subject: bug#14640: SA_RESTART prevents execution of signal handlers Date: Tue, 21 Jun 2016 11:46:37 +0200 Message-ID: <87eg7qc1s2.fsf@gnu.org> References: <87sj0gx2oq.fsf@inria.fr> <87twgn59ou.fsf@pobox.com> <87wpljdlta.fsf@inria.fr> <8737o73rbu.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1466502877 16712 80.91.229.3 (21 Jun 2016 09:54:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jun 2016 09:54:37 +0000 (UTC) Cc: 14640-done@debbugs.gnu.org To: Andy Wingo Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Tue Jun 21 11:54:27 2016 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bFINw-0006s0-Nc for guile-bugs@m.gmane.org; Tue, 21 Jun 2016 11:54:20 +0200 Original-Received: from localhost ([::1]:50271 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFINv-00075g-Or for guile-bugs@m.gmane.org; Tue, 21 Jun 2016 05:54:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFIGy-00088G-2i for bug-guile@gnu.org; Tue, 21 Jun 2016 05:47:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFIGs-0005lW-R1 for bug-guile@gnu.org; Tue, 21 Jun 2016 05:47:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFIGs-0005lS-NS for bug-guile@gnu.org; Tue, 21 Jun 2016 05:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bFIGs-0004f8-HK for bug-guile@gnu.org; Tue, 21 Jun 2016 05:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Tue, 21 Jun 2016 09:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14640 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 14640-done@debbugs.gnu.org id=D14640.146650241217903 (code D ref 14640); Tue, 21 Jun 2016 09:47:02 +0000 Original-Received: (at 14640-done) by debbugs.gnu.org; 21 Jun 2016 09:46:52 +0000 Original-Received: from localhost ([127.0.0.1]:48571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFIGi-0004eg-90 for submit@debbugs.gnu.org; Tue, 21 Jun 2016 05:46:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFIGg-0004eR-Ps for 14640-done@debbugs.gnu.org; Tue, 21 Jun 2016 05:46:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFIGX-0005iz-Ci for 14640-done@debbugs.gnu.org; Tue, 21 Jun 2016 05:46:45 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFIGX-0005ir-9V; Tue, 21 Jun 2016 05:46:41 -0400 Original-Received: from pluto.bordeaux.inria.fr ([193.50.110.57]:41350 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bFIGV-0005AC-LD; Tue, 21 Jun 2016 05:46:39 -0400 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 4 Messidor an 224 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <8737o73rbu.fsf@pobox.com> (Andy Wingo's message of "Tue, 21 Jun 2016 09:59:33 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.org gmane.lisp.guile.bugs:8070 Archived-At: Andy Wingo skribis: > On Tue 21 Jun 2016 09:48, ludovic.courtes@inria.fr (Ludovic Court=C3=A8s)= writes: > >> Andy Wingo skribis: >> >>> On Mon 17 Jun 2013 15:54, ludovic.courtes@inria.fr (Ludovic Court=C3=A8= s) writes: >>> >>>> When using SA_RESTART, signal handlers are never executed, as in this >>>> example (checked on 2.0.9+): >>>> >>>> (sigaction SIGALRM >>>> (lambda (signum) >>>> (pk 'sig signum)) >>>> SA_RESTART) >>>> (alarm 3) >>>> (pk 'char (read-char)) >>>> >>>> Presumably this is because the read(2) syscall is automatically >>>> restarted, leaving no chance for the handler async to run. >>> >>> Thinking about this a bit -- since we always handle signals >>> asynchronously and have no intention of handling them synchronously, >>> then we just have to document this behavior. Done in e877e1b: >> >> I think it=E2=80=99s problematic though. With the current design, signal >> delivery is unreliable (with or without SA_RESTART; what we observe with >> SA_RESTART occurs similarly if you make a syscall right after queuing, >> but not running, an async.) > > Can you expect any kind of reasonable behavior with SA_RESTART? I think > not. In C it does its job: signal handlers run, and other parts of the code don=E2=80=99t notice the interruption. Here it=E2=80=99s useless. >> The more I think about it, the more I think a different approach is >> needed. On GNU/Linux, signalfd(2) may be part of the solution. > > We already do the equivalent of signalfd(), with our self-pipe trick. Hmm, I wonder if it=E2=80=99s really equivalent. Also, it is internal: the Scheme level cannot explicitly =E2=80=9Cconvert= =E2=80=9D signals to FDs; all it gets is those asyncs. > And an fd doesn't help you if the syscall has no associated fd. But those typically don=E2=80=99t block. > If you are just concerned about read and write, I think the right thing > is non-blocking fd's, and making the C read/write waiters also add the > signal FD to their poll set. WDYT? There=E2=80=99s also =E2=80=98select=E2=80=99. In the case of the Shepherd= , you=E2=80=99re in a =E2=80=98select=E2=80=99 loop, waiting for events from file descriptors *an= d* waiting for SIGCHLD. However, the SIGCHLD handler can end up running long after the fact. In this case, it would help to explicitly use use =E2=80=98signa= lfd=E2=80=99 at the Scheme level (whether it=E2=80=99s used internally in libguile doesn= =E2=80=99t matter.) Not sure I follow your suggestion. My na=C3=AFve view is that one would probably expect/want signals to behave =E2=80=9Clike in C=E2=80=9D, meaning= that handlers would run in a timely fashion once the signal has effectively been received by libguile. Thanks for your feedback! Ludo=E2=80=99.