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

[Eli Zaretskii <eliz@gnu.org>]

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