On 09/05/2014 12:51 PM, Eli Zaretskii wrote: >> Date: Fri, 05 Sep 2014 11:51:00 +0100 >> From: Pedro Alves <pal...@redhat.com> >> CC: l...@gnu.org, guile-devel@gnu.org, gdb-patc...@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
