Re: Signal delivery

[Doug Evans]

On Tue, Feb 18, 2014 at 9:42 AM, Ludovic Courtès <address@hidden> wrote:
> (Dropping GDB.)
>
> Doug Evans <address@hidden> skribis:
>
>> On Tue, Feb 18, 2014 at 3:20 AM, Ludovic Courtès <address@hidden> wrote:
>
> [...]
>
>>> (I think we should aim to get rid of the signal-delivery thread
>>> eventually, and I remember Mark mentioned it before too.)
>>
>> Note that Python queues the asyncs directly from the signal handler,
>> even when it has thread support.
>> I'm not sure if there are any problems in Python's implementation;
>> asyncs can be queued from any thread but only the main thread runs them.
>>
>> Guile would need to come up with its own implementation of course;
>> plus Guile can direct signals to any thread.
>
> There are two difficulties:
>
>   1. The signal handler can only call async-signal-safe functions, which
>      complicates things.

That's why I'm curious whether Python's solution has any problems.
Someone (potentially not a Guile developer - not sure how to address
copyright issues) should look into that.  I will I hope, dunno how
soon though.

>   2. In Guile, the 'sigaction' procedure can specify the thread that
>      will run the async.
>
> Ludo'.

Guile solves that by registering ahead of time which thread.
I don't see it as an added difficulty.

btw, I'm testing a patch that proposes augmenting Guile's signal
handling support.
sigaction tries to do too much.  For some apps libguile needs to
provide something with a finer granularity, so to speak.

I see (at least) two high level problems.

1) Some apps need ability to use their own signal handlers.
2) Remove need for a separate thread.

I'm not addressing (2) in this patch, though I am allowing for the day
when the signal delivery thread is gone (the API needn't change).

I'm addressing (1) by exporting two things:
a) ability to record a signal with Guile in an async-safe way (for the
present implementation that means basically by exporting the
pipe-writing part of take_signal).
b) ability to specify in advance which function to call and on which
thread to process the signal, basically by exporting install_handler.

I need to make sure these play well with sigaction.  I haven't come
across any problems, but it's early. :-)

Thoughts?