This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2] Improved ^c support for gdb/guile


On Tue, Feb 18, 2014 at 3:20 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Right, when Guile is built with pthread support, it has a signal
> delivery thread.  The actual SIGINT handler ('take_signal' in scmsigs.c)
> just write one byte to a pipe; the signal delivery thread reads from
> that pipe, and queues an async in the destination thread for later
> execution.
>
>> I'll let guile-devel take over at this point - I understand the code,
>> but may miss something noteworthy.
>> There is code in scmsigs.c to handle the non-pthread case but it's not
>> clear how much is exported nor how well it works.
>
> The non-pthread code is used when Guile is built without pthread
> support.  In that case, the async is queued directly from the signal
> handler.
>
> (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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]