This is the mail archive of the 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][PR guile/17247] Block SIGCHLD while initializing Guile

On 09/05/2014 12:51 PM, Eli Zaretskii wrote:
>> Date: Fri, 05 Sep 2014 11:51:00 +0100
>> From: Pedro Alves <>
>> CC:,,
>> 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.


Pedro Alves

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