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>, Doug Evans <xdje42 at gmail dot com>
- Cc: ludo at gnu dot org, guile-devel at gnu dot org, gdb-patches at sourceware dot org
- Date: Fri, 05 Sep 2014 11:51:00 +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>
On 09/05/2014 09:48 AM, Eli Zaretskii wrote:
>> From: Doug Evans <email@example.com>
>> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
>> Date: Fri, 05 Sep 2014 01:26:28 -0700
>> we can't physically prevent [users] from starting threads.
> Of course we can: if Guile gives us a way to disable threads, any user
> extension that attempts to start a thread will simply fail.
>> We pretty much leave them that way already given the myriad
>> of things they can do to mess up gdb without threads.
> ?? The rest of GDB is compiled C code which users cannot change
> without recompiling. And it's a single-threaded code. And it's under
> our close scrutiny. So I see no problems here.
>> The python side of things is too silent on whether threads are supported
I'd be strongly against preventing extensions from using threads. As an
example, tromey's wip/prototype gdb frontend written as a python extension to
gdb uses threads:
Even GDB itself isn't really strictly single-threaded -- e.g., on
Windows, we spawn threads to handle I/O:
ser-mingw.c: state->thread = CreateThread (NULL, 0, thread_fn, scb, 0, &threadId);
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.