[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Signal delivery
From: |
Doug Evans |
Subject: |
Re: Signal delivery |
Date: |
Tue, 18 Feb 2014 09:56:49 -0800 |
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?
- Re: MinGW patches, (continued)
- Re: MinGW patches, Eli Zaretskii, 2014/02/22
- Re: MinGW patches, Eli Zaretskii, 2014/02/22
- Re: MinGW patches, Mark H Weaver, 2014/02/22
- Re: MinGW patches, Eli Zaretskii, 2014/02/22
- Re: MinGW patches, Mark H Weaver, 2014/02/23
- Re: MinGW patches, Eli Zaretskii, 2014/02/23
- Re: [PATCH v2] Improved ^c support for gdb/guile, Mark H Weaver, 2014/02/19
- Re: [PATCH v2] Improved ^c support for gdb/guile, Eli Zaretskii, 2014/02/19
- Re: [PATCH v2] Improved ^c support for gdb/guile, Doug Evans, 2014/02/18
- Signal delivery, Ludovic Courtès, 2014/02/18
- Re: Signal delivery,
Doug Evans <=
- Re: Signal delivery, Ludovic Courtès, 2014/02/18
- Re: Signal delivery, Doug Evans, 2014/02/18