[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile
From: |
Pedro Alves |
Subject: |
Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile |
Date: |
Fri, 05 Sep 2014 13:48:25 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 |
On 09/05/2014 12:51 PM, Eli Zaretskii wrote:
>> Date: Fri, 05 Sep 2014 11:51:00 +0100
>> From: Pedro Alves <address@hidden>
>> CC: address@hidden, address@hidden, address@hidden
>>
>> 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
undefined territory.
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.
Ack.
Thanks,
Pedro Alves
- Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile, (continued)
- Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile, Doug Evans, 2014/09/01
- Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile, Eli Zaretskii, 2014/09/01
- Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile, Ludovic Courtès, 2014/09/01
- Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile, Eli Zaretskii, 2014/09/01
- Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile, Doug Evans, 2014/09/01
- Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile, Eli Zaretskii, 2014/09/02
- Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile, Doug Evans, 2014/09/05
- Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile, Eli Zaretskii, 2014/09/05
- Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile, Pedro Alves, 2014/09/05
- Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile, Eli Zaretskii, 2014/09/05
- Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile,
Pedro Alves <=
- Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile, Ludovic Courtès, 2014/09/05