For threads, we have a nice API in SRFI 18.

For signals, we need a higher abstraction than the POSIX layer. A
signal in this higher abstraction layer could be delivered to a thread
through "raise-continuable". At that point, the C signal handler would
have long been left. In particular, the usual restrictions that apply
to C signal handlers wouldn't apply. However, there would be no
guarantee that the signal is delivered immediately but only at the
next safepoint (which would be implementation-defined).

Marc

Am Do., 6. Aug. 2020 um 16:22 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> >> SIGWINCH handler
>
> > Yeah, while I haven't dealt with them since 1994, signal handling is
> > no fun at all.  But needed ... John et. al., is signal handling needed
> > for any other future SRFIs/R7RS-large you envision?  Your GitHub repo
> > https://github.com/johnwcowan/r7rs-work doesn't have any file with the
> > string signal in it.  PosixLua.md, what Lua provides in it's POSIX API
> > has the following:
> >
> > posix-signal: kill (pid, opt)
> > posix-signal: killpg (pgrp[, sig=`SIGTERM`])
> > posix-signal: raise (sig)
> > posix-signal: signal (signum[, handler=SIG_DFL[, flags]])
> >
> > PosixLinks.md has this Chicken 5 egg:
> >
> > https://wiki.call-cc.org/man/5/Module%20(chicken%20process%20signal)
> >
> > If another SRFI needs signal handling, or a general POSIX signal
> > handling SRFI is a good idea, facilities to supply the above desired
> > SIGWINCH handler should be in it.  Even if we don't envision any of
> > this today, we should still almost certainly put this in another SRFI
> > because of how much of a burden it would otherwise add to an
> > implementor of SRFI 205, or an "ANSI terminal fundamentals" SRFI.
>
> Thanks for doing the above survey!
>
> Unfortunately signal handling ties in an extremely subtle way into a
> Scheme implementation's multithreading and GC systems, and probably into
> continuations as well. It's a minefield even in C; in Scheme, I wouldn't
> dare specify any portable signals+threads API. Let's leave that to the
> experts on our lists who have maintained a multi-threaded,
> cross-platform Scheme implementation for many years.
>
> For the terminal library, all we really need is a way for someone to
> notify it whenever the window size signal has been received. I'd advise
> that we only export such a procedure from the ANSI terminal SRFI
> (whether it's SRFI 205 or a future one).