This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Pedro Alves <palves at redhat dot com>
- Cc: xdje42 at gmail dot com, ludo at gnu dot org, guile-devel at gnu dot org, gdb-patches at sourceware dot org
- Date: Fri, 05 Sep 2014 14:51:38 +0300
- Subject: Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile
- Authentication-results: sourceware.org; auth=none
- References: <m31trwv5o1 dot fsf at sspiff dot org> <834mwsh2nu dot fsf at gnu dot org> <CAP9bCMTNsoi6AhQxJtzjc6=o9iHi8TXkX32OiKbArAuAnsjZUQ at mail dot gmail dot com> <8338ccgj78 dot fsf at gnu dot org> <87ppffabw8 dot fsf at gnu dot org> <83y4u3flr2 dot fsf at gnu dot org> <87r3zv71qy dot fsf at gnu dot org> <83vbp7fer3 dot fsf at gnu dot org> <CAP9bCMR_=pCw9mF6CDFBnf0J+_Rw9AZAhVh8pFEizjyVWJ1+dw at mail dot gmail dot com> <83iol6f3iy dot fsf at gnu dot org> <m3lhpytqvf dot fsf at sspiff dot org> <83a96ee9lk dot fsf at gnu dot org> <54099594 dot 2000201 at redhat dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Fri, 05 Sep 2014 11:51:00 +0100
> From: Pedro Alves <firstname.lastname@example.org>
> CC: email@example.com, firstname.lastname@example.org, email@example.com
> 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