Signal handling Lassi Kortela (06 Aug 2020 14:22 UTC)
Re: Signal handling Marc Nieper-Wißkirchen (06 Aug 2020 14:32 UTC)
Re: Signal handling John Cowan (06 Aug 2020 15:13 UTC)
Re: Signal handling Arthur A. Gleckler (06 Aug 2020 15:28 UTC)
Re: Signal handling John Cowan (06 Aug 2020 17:38 UTC)
Re: Signal handling Arthur A. Gleckler (06 Aug 2020 18:19 UTC)
Re: Signal handling Lassi Kortela (06 Aug 2020 18:35 UTC)
Re: Signal handling Amirouche Boubekki (06 Aug 2020 21:18 UTC)
Re: Signal handling Amirouche Boubekki (06 Aug 2020 21:23 UTC)
Re: Signal handling John Cowan (07 Aug 2020 02:56 UTC)
Re: Signal handling Marc Nieper-Wißkirchen (06 Aug 2020 15:32 UTC)
Re: Signal handling John Cowan (06 Aug 2020 16:38 UTC)
Re: Signal handling hga@xxxxxx (06 Aug 2020 14:33 UTC)
Signal handling with terminals Lassi Kortela (06 Aug 2020 14:54 UTC)
(missing)
UI event datatypes Lassi Kortela (06 Aug 2020 16:08 UTC)
Re: UI event datatypes John Cowan (06 Aug 2020 16:34 UTC)
Re: UI event datatypes Lassi Kortela (06 Aug 2020 16:57 UTC)
Re: UI event datatypes John Cowan (07 Aug 2020 21:30 UTC)
Re: UI event datatypes Lassi Kortela (08 Aug 2020 18:36 UTC)
Re: UI event datatypes John Cowan (09 Aug 2020 00:31 UTC)

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