From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28403 invoked by alias); 21 Nov 2008 02:09:44 -0000 Received: (qmail 28264 invoked by uid 22791); 21 Nov 2008 02:09:34 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 21 Nov 2008 02:08:26 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mAL28I6p005363 for ; Thu, 20 Nov 2008 21:08:18 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mAL28Gxt008271; Thu, 20 Nov 2008 21:08:17 -0500 Received: from opsy.redhat.com (vpn-13-160.rdu.redhat.com [10.11.13.160]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mAL28GmB015988; Thu, 20 Nov 2008 21:08:16 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 69AD23787AB; Thu, 20 Nov 2008 19:08:15 -0700 (MST) To: gdb-patches@sourceware.org Subject: Re: RFA: properly handle the GIL References: <20081121014907.GA19748@caradoc.them.org> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Fri, 21 Nov 2008 19:13:00 -0000 In-Reply-To: <20081121014907.GA19748@caradoc.them.org> (Daniel Jacobowitz's message of "Thu\, 20 Nov 2008 20\:49\:07 -0500") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 X-SW-Source: 2008-11/txt/msg00578.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> This looks OK. Is this a recursive lock? That is, do we have to Daniel> worry about GDB -> Python -> GDB -> Python taking the lock twice? We don't have to worry. Python provides several APIs to the GIL; the one that we use is reentrant. Sorry for not mentioning this before -- I forgot about it. Also, I realized people may be wondering about thread safety in gdb. For the time being I think we should just ignore this and require that Python scripts be careful to run code in gdb's thread. I'll commit this tomorrow. Tom