[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 17:58:37 -0800 |
On Tue, Feb 18, 2014 at 3:06 PM, Ludovic Courtès <address@hidden> wrote:
> Doug Evans <address@hidden> skribis:
>
>> I see (at least) two high level problems.
>>
>> 1) Some apps need ability to use their own signal handlers.
>
> You mean the "real" signal handler, right?
Right.
>> 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.
>
> Sounds like a plan. I wonder if this might expose too much, but we'll
> see with the patch. :-)
If we can agree that libguile should support an app installing it's
own "real" signal handler then (a) falls out from that, and (b)
doesn't export anything that sigaction doesn't already export.
I'll hopefully have a patch ready in a few days (it's trivial, but
I've owe other folks some patches :-)).
> Thanks for looking into this!
>
> Ludo'.
- Re: MinGW patches, (continued)
- 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, 2014/02/18
- Re: Signal delivery, Ludovic Courtès, 2014/02/18
- Re: Signal delivery,
Doug Evans <=