Email list hosting service & mailing list manager


Re: Signal handling hga@xxxxxx 06 Aug 2020 14:33 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Thursday, August 06, 2020 9:22 AM
>
>>> 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!

You're welcome.

> 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.

So you don't think it's possible to create a Scheme level portable
across implementations API?  I would not be surprised.

> Let's leave that to the experts on our lists who have maintained a
> multi-threaded, cross-platform Scheme implementation for many years.

I'm CCing this to srfi-discuss to get more opinions.

> 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).

So ANSI terminal fundamentals, wherever they get put, are could have
a highest level API that does whatever unspecified magic is required
to both set up the handler and get events from it?

Or you could call ioctl frequently to see if the size has changed....

- Harold