Re: SCM_SYSCALL

[Mark H Weaver <mhw@netris.org>]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:
> I’ve been cooking a patch but the test case ends up being trickier to
> write than I expected.  Here’s 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
> ‘system-error’ with EINTR.
>
> However, with a fixed SCM_SYSCALL, the result is pretty much the same as
> with SA_RESTART (see <http://bugs.gnu.org/14640>): when SCM_ASYNC_TICK
> is called right after we get EINTR, chances are that the async hasn’t
> 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 “better”, 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