On Sat, May 11, 2019 at 3:31 AM Shiro Kawai <xxxxxx@gmail.com> wrote:

Short summary:
(1) Make Scheme signal handler free from limitations of what you can do in POSIX
signal handler.

Agreed. A Scheme signal handler should be able to do anything.

I like the idea of a dedicated thread, though obviously we can't impose it as part of the standard until and unless we standardize on OS-level threads (which we might not; SRFI 18 works fine with green threads as well).

(2) We could make the runtime restart the interrupted system calls If we want to
abort the call we can just jump out from the Scheme signal handler.

The current draft requires all syscalls to be restarted, so EINTR is never raised as an exception. That makes it impossible to abort the call, but I don't consider that a problem.

One option is to let the system's signal handler to set a flag indicating
the signal is delivered, and later, at the "safe" point, check the flag and invoke
Scheme signal handler if necessary. This doesn't work with synchronous signals,
but they're out of scope of srfi-170.

Trapping them is out of scope, but deciding whether to ignore them or die on them is still allowed.

If we take this option, handling of EINTR needs care; if we just throw an exception
immediately when a syscall returns an error, the exception is raised before a Scheme
signal handler is ever called, which doesn't seem to be very useful.

I think that's exactly right. A syscall error is synchronous, and there's no reason to invoke a *signal* handler; rather an *exception* handler (which is a very different thing) is called.

At least,
the implementation should check the signal delivery and invoke Scheme signal
handler necessary when a syscall returns an error with errno = EINTR.

No need to mess with signals. If errno = EINTR, retry; if not, invoke the current exception handler from the dynamic environment.

I feel it's more sensible
to make the runtime restarts the syscall if it returns an error with EINTR, instead
of throwing an exception on it.

Exactly.

Note that if you want otherwise, that is, you don't
want to restart the syscall, you can just throw your own exception from the signal handler.

But if the exception handler has not been entered on EINTR (which I think is correct), there is no recovery.

I have the feeling that I am not understanding you correctly.

There are a few POSIX syscalls that doesn't go well with this delayed-signal-handling
and automatic restarting, though they're not included in srfi-170.
I list them for the future reference.

There are other cases as well: if read() is interrupted after some bytes have been read,

you need to increment the buffer pointer and decrement the length.

John Cowan http://vrici.lojban.org/~cowan xxxxxx@ccil.org

Raffiniert ist der Herrgott, aber boshaft ist er nicht.

--Albert Einstein