Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile

[Pedro Alves <palves@redhat.com>]

On 09/05/2014 09:48 AM, Eli Zaretskii wrote:
>> From: Doug Evans <xdje42@gmail.com>
>> Cc: ludo@gnu.org,  guile-devel@gnu.org,  gdb-patches@sourceware.org
>> Date: Fri, 05 Sep 2014 01:26:28 -0700
>>
>> we can't physically prevent [users] from starting threads.
> 
> Of course we can: if Guile gives us a way to disable threads, any user
> extension that attempts to start a thread will simply fail.
> 
>> We pretty much leave them that way already given the myriad
>> of things they can do to mess up gdb without threads.
> 
> ?? The rest of GDB is compiled C code which users cannot change
> without recompiling.  And it's a single-threaded code.  And it's under
> our close scrutiny.  So I see no problems here.
> 
>> The python side of things is too silent on whether threads are supported
>> there.
>> https://sourceware.org/gdb/current/onlinedocs/gdb/Basic-Python.html#Basic-Python

I'd be strongly against preventing extensions from using threads.  As an
example, tromey's wip/prototype gdb frontend written as a python extension to
gdb uses threads:

 https://gitorious.org/gdb-gui

Even GDB itself isn't really strictly single-threaded -- e.g., on
Windows, we spawn threads to handle I/O:

  ser-mingw.c:  state->thread = CreateThread (NULL, 0, thread_fn, scb, 0, &threadId);

Just last night I was debugging something in non-stop mode
where a ton of events happen behind the scenes without causing
a user-visible stop (a bunch of parallel single-steps), and
noticing how the cli/prompt becomes so unresponsive, because the event
loop handles either target events or input events in sequence, not
in parallel, and thinking that probably to completely fix this we'd
need to move stdin/readline handling to a separate thread.

Thanks,
Pedro Alves