From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10392 invoked by alias); 17 Oct 2014 17:31:16 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 10381 invoked by uid 89); 17 Oct 2014 17:31:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 17 Oct 2014 17:31:14 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9HHV9WG001504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 17 Oct 2014 13:31:09 -0400 Received: from localhost.localdomain (ovpn-112-31.ams2.redhat.com [10.36.112.31]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9HHV8cN019962; Fri, 17 Oct 2014 13:31:08 -0400 Message-ID: <5441525B.3040801@redhat.com> Date: Fri, 17 Oct 2014 17:31:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: Paul_Koning@dell.com CC: omeragacan@gmail.com, gdb@sourceware.org Subject: Re: recursion limit exceeded in Python API, but there's only one function in traceback References: <543FBDFF.3050709@redhat.com> <104DEFBD-D686-4290-8E3C-725A51C165E6@dell.com> <7BB30632-15BE-4EF8-B84F-D35A27772F18@dell.com> <5440EB39.2060305@redhat.com> <2BD7D737-CFF3-4368-9265-25C6611CF40C@dell.com> In-Reply-To: <2BD7D737-CFF3-4368-9265-25C6611CF40C@dell.com> Content-Type: text/plain; charset=windows-1254 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00078.txt.bz2 On 17/10/14 16:04, Paul_Koning@dell.com wrote: > > On Oct 17, 2014, at 6:11 AM, Phil Muldoon wrote: > >> ... >> Right. gdb.execute won't return until the command has completed. >> Also the Python GIL has been acquired (as this is coming from the >> Python interpreter) and so now Python is also blocked too. So in >> effect the only thing running at this point is the gdb.execute command >> that was invoked (in your case, the continue command). That will >> return, and then the Python GIL will be released and the rest of the >> script will continue. >> >> I have a patch I need to upstream that adds a release_gil keyword to >> gdb.execute. This optionally releases the GIL before executing the >> command. But I have not got around to that yet. > > Could you explain why gdb.execute should ever hold onto the GIL while performing the command? I view gdb.execute as akin to an I/O operation, which releases the GIL around the I/O. Another way to look at it is that execute is performing a GDB command. Either that isn’t a Python operation — in which case the GIL is not needed since the data it protects won’t be touched. Or it is a command that (possibly indirectly) invokes another Python operation — in which case the GIL has to be released or you end up with a deadlock. > It (GDB) is not holding the GIL, Python is. The gdb.execute call at that point has been called from the Python interpreter, and it has managed the GIL until that point. This means in current behavior, say you had three threads running, they are all suspended during the call to gdb.execute. A user submitted a request that we release the GIL (even though GDB did not acquire it). The patch that I will submit (soon) just releases the GIL so that on long-lived operations Python threads can still continue to execute. It does this with SaveThread/RestoreThread. There is more detail on this in the bugzilla posted. Cheers Phil