> 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 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.
