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

[Pedro Alves <palves@redhat.com>]

On 09/05/2014 12:51 PM, Eli Zaretskii wrote:
>> Date: Fri, 05 Sep 2014 11:51:00 +0100
>> From: Pedro Alves <palves@redhat.com>
>> CC: ludo@gnu.org, guile-devel@gnu.org, gdb-patches@sourceware.org
>>
>> I'd be strongly against preventing extensions from using threads.
> 
> Then how do you propose to deal with the difficulties I listed in one
> of my previous messages?

As you said, both Guile and Python support loading foreign
libraries, so those difficulties aren't really specific
to multi-threading.  Even without loading foreign
libraries, it seems to me that a single-threaded extension
script can just as well mess up gdb, but doing some of the things
you list, like e.g., messing with signal handlers and timers.

So I think we should say that you mustn't change global
environment behind gdb's feet, and if you do so, you're in
undefined territory.

I thikn we also need to make clear that you can _only_ interact
with GDB through the main thread.  You can't have a random
thread call into GDB's APIs, as there's no locking.

> 
>> As an example, tromey's wip/prototype gdb frontend written as a
>> python extension to gdb uses threads:
> 
> You don't need to convince me that forbidding threads takes away some
> significant functionality.  This is a question of finding the right
> balance, not whether threads are useful.
> 
>> Even GDB itself isn't really strictly single-threaded -- e.g., on
>> Windows, we spawn threads to handle I/O:
> 
> That just means we already take some risk, where no other solution was
> possible, or reasonably practical.  It does not mean we should from
> now on be casual about adding more of that.  Moreover, this is _us_
> doing threads, not users on whose code we have no control.
> 
>> 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.
> 
> It's fine with me to redesign GDB to be a multi-threaded program.  But
> you know better than I do how deeply single-threaded is the current
> GDB design.  I'm talking about allowing threads with arbitrary code
> into our back-door, while GDB currently doesn't and cannot handle that
> very well.

Ack.

Thanks,
Pedro Alves