From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28659 invoked by alias); 3 Oct 2011 10:22:21 -0000 Received: (qmail 28650 invoked by uid 22791); 3 Oct 2011 10:22:20 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_GJ X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Oct 2011 10:22:06 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p93AM5B7019445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Oct 2011 06:22:05 -0400 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p93AM493006795; Mon, 3 Oct 2011 06:22:04 -0400 From: Phil Muldoon To: Jan Kratochvil Cc: Paul Koning , gdb-patches@sourceware.org Subject: Re: Python: fetch value when building gdb.Value object References: <36B29E9D-F2B3-446F-AF8A-97254A3AAEE2@comcast.net> <20111001090443.GA11227@host1.jankratochvil.net> Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Mon, 03 Oct 2011 10:22:00 -0000 In-Reply-To: <20111001090443.GA11227@host1.jankratochvil.net> (Jan Kratochvil's message of "Sat, 1 Oct 2011 11:04:43 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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: 2011-10/txt/msg00018.txt.bz2 Jan Kratochvil writes: > On Wed, 28 Sep 2011 22:40:50 +0200, Paul Koning wrote: >> If I use RETURN_MASK_ERROR and control/C is hit, does that mean the >> currently running code aborts and the outer handler that does have >> RETURN_MASK_ALL is entered? > > Yes. > >> If so, most of the Python code seems to be a candidate for >> RETURN_MASK_ERROR. > > In fact I do not know, it is a Python thing. > > RETURN_MASK_ALL is right if returned PyExc_KeyboardInterrupt will really abort > any execution of Python code. It is probably so, as suggested by: > http://docs.python.org/library/exceptions.html#exceptions.KeyboardInterrupt > > RETURN_MASK_ERROR is right otherwise, but only if it is safe to longjmp out > from a code called by Python. This may not be true. Python may be C++ > exceptions throwing safe but it cannot be safe for the GDB longjmp exceptions. > But this case would mean Python is buggy for CTRL-C on its own so > RETURN_MASK_ERROR probably is not right. Jan asked me to look at all the cases. I just have not had time to do it yet. Too me, the RETURN_MASK in many cases in the Python code is far too liberal, and should, as Jan notes, be reduced to RETURN_MASK_ERROR. I am not sure it is just a mechanical change as each scenario has to be carefully reviewed to understand if in fact an interrupt should be allowed according to the Python API. Cheers, Phil