[Top][All Lists]

[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?


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]