This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile
- From: Pedro Alves <palves at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- 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 13:48:25 +0100
- 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> <838ulye14l dot fsf at gnu dot org>
On 09/05/2014 12:51 PM, Eli Zaretskii wrote:
>> Date: Fri, 05 Sep 2014 11:51:00 +0100
>> From: Pedro Alves <email@example.com>
>> CC: firstname.lastname@example.org, email@example.com, firstname.lastname@example.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
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.