From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: SCM_SYSCALL Date: Fri, 05 Jul 2013 14:56:08 -0400 Message-ID: <878v1kbzuf.fsf@tines.lan> References: <87li607c5l.fsf@gnu.org> <878v1nfqvn.fsf@tines.lan> <87zju27yeq.fsf@inria.fr> 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 1373050599 22296 80.91.229.3 (5 Jul 2013 18:56:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jul 2013 18:56:39 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jul 05 20:56:39 2013 Return-path: Envelope-to: guile-devel@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 1UvBBP-0003JN-2F for guile-devel@m.gmane.org; Fri, 05 Jul 2013 20:56:39 +0200 Original-Received: from localhost ([::1]:57014 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvBBO-0003yE-Pt for guile-devel@m.gmane.org; Fri, 05 Jul 2013 14:56:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvBBK-0003xt-UD for guile-devel@gnu.org; Fri, 05 Jul 2013 14:56:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UvBBJ-00055t-GT for guile-devel@gnu.org; Fri, 05 Jul 2013 14:56:34 -0400 Original-Received: from world.peace.net ([96.39.62.75]:36480) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvBBJ-00055o-CA; Fri, 05 Jul 2013 14:56:33 -0400 Original-Received: from 209-6-120-240.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com ([209.6.120.240] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UvBBB-0000kg-Vl; Fri, 05 Jul 2013 14:56:26 -0400 In-Reply-To: <87zju27yeq.fsf@inria.fr> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22\?\= \=\?utf-8\?Q\?'s\?\= message of "Fri, 05 Jul 2013 00:28:29 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16513 Archived-At: Hi Ludovic, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > I=E2=80=99ve been cooking a patch but the test case ends up being trickie= r to > write than I expected. Here=E2=80=99s what I have: > > (let* ((in+out (pk 'pipe (pipe))) > (lock (make-mutex)) > (cond (make-condition-variable)) > (signaled #f) > (thread (call-with-new-thread > (lambda () > (with-mutex lock > (display "hello " (cdr in+out)) > (wait-condition-variable cond lock) > (display "world\n" (cdr in+out)) > (close-port (cdr in+out))))))) > (define handle > (lambda (signum) > (with-mutex lock > (set! signaled (pk 'sig signum)) > (signal-condition-variable cond)))) > (sigaction SIGALRM handle 0) > (alarm 2) > > ;; This thread (the main thread) receives the signal. Yet, > ;; the EINTR returned by read(2) as called via `read-line' > ;; must be swallowed. > (let ((line (read-line (car in+out)))) > (join-thread thread) > (list signaled line))) > > This nicely reproduces the problem where fport_fill_input throws to > =E2=80=98system-error=E2=80=99 with EINTR. > > However, with a fixed SCM_SYSCALL, the result is pretty much the same as > with SA_RESTART (see ): when SCM_ASYNC_TICK > is called right after we get EINTR, chances are that the async hasn=E2=80= =99t > been queued yet, so we get back to our read(2) call, and thus the > Scheme-level signal handler is never called. (Typically, when running > the test through strace, it passes, because the timing is =E2=80=9Cbetter= =E2=80=9D, but > it fails without strace.) > > Suggestions? Hmm. Shouldn't our signal handlers be run in a different thread? Maybe we can't make this change until 2.2, but it seems to me that there are very serious problems trying to run signal handlers from within asyncs, analogous to the problems running finalizers within asyncs. Commonly, signal handlers need to mutate some global state, but that cannot in general be done safely from within asyncs, because asyncs might be called while the global state is in an inconsistent state, at least for data structures implemented in Scheme. What do you think? Mark