Re: SCM_SYSCALL

[Ludovic Courtès]

Hi Mark!

Mark H Weaver <address@hidden> skribis:

> address@hidden (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?

I think the rationale was that signal handlers in Guile would be a
simplified version of what POSIX provides.  That is, they are called in
the thread that called ‘sigaction’, and there are no restrictions on
what procedures can be used from within the handler.  From that
perspective, I think it fits the bill.

Now, of course that introduces concurrency, but that’s what signals are
about anyway: asynchronous notifications.  Thus I don’t have any
particular problems with this implementation.

Am I overlooking other issues you had in mind?

Thanks,
Ludo’.