From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118306 invoked by alias); 10 Oct 2018 14:38:17 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 118290 invoked by uid 89); 10 Oct 2018 14:38:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=today!, H*r:sk:i8-v6so X-HELO: mail-wm1-f48.google.com Received: from mail-wm1-f48.google.com (HELO mail-wm1-f48.google.com) (209.85.128.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 10 Oct 2018 14:38:10 +0000 Received: by mail-wm1-f48.google.com with SMTP id i8-v6so5721430wmg.0 for ; Wed, 10 Oct 2018 07:38:09 -0700 (PDT) Return-Path: Received: from ?IPv6:2a02:c7f:ae6a:ed00:4685:ff:fe66:9f4? ([2a02:c7f:ae6a:ed00:4685:ff:fe66:9f4]) by smtp.gmail.com with ESMTPSA id e21-v6sm17429615wma.8.2018.10.10.07.38.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Oct 2018 07:38:06 -0700 (PDT) Subject: Re: [RFC] Release the GIL while running a gdb command or expression To: Tom Tromey Cc: gdb-patches@sourceware.org References: <20180915040732.6718-1-tom@tromey.com> <807f284a-e227-37ed-c197-170a7f2abe40@redhat.com> <874ldugb5e.fsf@tromey.com> <6503980f-f5ab-ecab-37a5-993d9daec226@redhat.com> <87va69evyl.fsf@tromey.com> From: Phil Muldoon Message-ID: <77d79d93-3ba5-090b-9c90-1b33c0f9b637@redhat.com> Date: Wed, 10 Oct 2018 14:38:00 -0000 MIME-Version: 1.0 In-Reply-To: <87va69evyl.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00260.txt.bz2 On 10/10/2018 15:07, Tom Tromey wrote: >>>>>> "Phil" == Phil Muldoon writes: > >>> I don't think this is necessary, mostly because I can't think of when it >>> would be desirable not to release the GIL; but also because when writing >>> Python one doesn't normally have to worry about the GIL -- it's not >>> really a Python-visible feature, nor should it be, since implementations >>> like PyPY don't have it. > > Phil> It's not so much an implementation detail that should be exposed to > Phil> the user but rather a change in behavior around gdb.execute. Given > Phil> that now, with this patch, we always release the Python GIL during the > Phil> execution of a GDB command via gdb.execute, any other Python thread > Phil> that was previously blocked by the GIL is now unblocked, and it may > Phil> appear to those threads that the Python thread that initiated the > Phil> gdb.execute has returned from that command when it may not have (this > Phil> is especially so in cases where a GDB command takes seconds to > Phil> complete a command). Also, any other Python threads that wish to > Phil> interact with GDB will have to wait until the GDB event loop returns > Phil> to a state where it is accepting input (at least I think this is > Phil> true). > > Actually we forbid using gdb APIs from threads other than the gdb > thread. From python.texi: > > @value{GDBN} is not thread-safe. If your Python program uses multiple > threads, you must be careful to only call @value{GDBN}-specific > functions in the @value{GDBN} thread. @code{post_event} ensures > this. Aha, well I learned something new today! > Phil> This may break some scripts out there. Are these scripts > Phil> relying on what we now classify as a bug or is there is a reasonable > Phil> expectation, on the users' behalf, that a script could rely on GDB's > Phil> previous GIL blocking behavior? I'm not advocating we should have a > Phil> release_gil parameter, I'm just unsure of the expectations of users > Phil> and scripts out there, and that if we don't provide a mechanism to > Phil> optionally block the GIL, it will cause disruption to any established > Phil> scripts out there. > > Phil> I suppose the solution is to either provide a GIL blocking parameter > Phil> or to thoroughly document this new behavior in the manual. What do > Phil> you think? > > I think there's little risk of this breaking anything. It seems like > just an ordinary bug fix to me. Ok. I looked at the patch and, from my point of view, it looks fine to me. I'll leave any testing decisions in your hands. Cheers Phil