From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28540 invoked by alias); 22 Jan 2012 16:32:49 -0000 Received: (qmail 28526 invoked by uid 22791); 22 Jan 2012 16:32:48 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from router-304.cs.umd.edu (HELO bacon.cs.umd.edu) (128.8.127.145) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 22 Jan 2012 16:32:35 +0000 Received: from [10.61.40.39] (unknown [70.42.157.21]) (Authenticated sender: khooyp) by bacon.cs.umd.edu (Postfix) with ESMTPSA id 38ED7B4015E; Sun, 22 Jan 2012 11:32:31 -0500 (EST) Subject: Re: Handle SIGINT in Python Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Khoo Yit Phang In-Reply-To: Date: Sun, 22 Jan 2012 16:36:00 -0000 Cc: Khoo Yit Phang , gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1FE2845A-162C-48D7-A3D0-C0F2D6DFA09B@cs.umd.edu> To: Tom Tromey X-CSD-MailScanner-ID: 38ED7B4015E.A9F24 X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-50, required 5, autolearn=not spam, ALL_TRUSTED -50.00) X-CSD-MailScanner-From: khooyp@cs.umd.edu X-CSD-MailScanner-Watermark: 1327854752.95031@au/G8On17pZ13RNdT/yqhA 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: 2012-01/txt/msg00754.txt.bz2 Hi, On Jan 20, 2012, at 4:33 PM, Tom Tromey wrote: >>>>>> "Yit" =3D=3D Khoo Yit Phang writes: >=20 > Tom> Could we possibly solve this problem without constantly resetting the > Tom> SIGINT handler? Maybe via a combination of a global flag plus a call > Tom> into Python from handle_sigint? >=20 > Yit> It is possible, I just need a way to call PySet_Interrupt. But it > Yit> seems to be that it would require adding hooks to events-top.c and, > Yit> which seems like a separate project. >=20 > I think of it more as a different implementation of the feature... In the long run, I do think that changing events-top.c is better, but I've = to figure out how it should look like, for Python and other clients. > Tom> Our python->gdb exception story is not super. And, we lose informat= ion > Tom> in the round trip. This might (or might not...) be a prerequisite to > Tom> solving this problem. >=20 > Yit> I don't think it's a problem, unless for nested calls to python like > Yit> "py gdb.execute('py ...')". >=20 > You can't fully predict what gdb actions will cause Python code to run. Actually, I don't think I understand what you mean. Can you give an example= ? (Is it related to scenario 1 below?) > Also, Python frequently calls into gdb. Any place in gdb that invokes > QUIT could potentially see a C-c. However, IIUC, with your patch these > QUITs will be inactive if there is Python code up the stack -- but this > means that some slow things in gdb will be uninterruptible. I think there are two scenarios here: 1. When the call stack is GDB -> Python, Ctrl-C will only interrupt the Pyt= hon part (unless there's special handling in the GDB part to treat Keyboard= Interrupt). You would have to press Ctrl-C again to interrupt the GDB part = immediately after. I wondered whether to have Ctrl-C interrupt the entire s= tack; it's fairly easy to do, since every Python entry is wrapped by ensure= _python_env (just check for KeyboardInterrupt during cleanup and raise QUIT= ). Though, there was some debate earlier in the mailing list on something rela= ted: whether Ctrl-C during gdb.execute should interrupt Python too. The con= cern was that there may be legitimate reasons to interrupt only part of the= call stack, and the decision should depend on the particulars of the task. 2. When the call stack is GDB -> Only gdb.execute is interruptible now, sin= ce that's the only place I've suspended Python's interrupt handler. There m= ay be other Python methods that call into GDB that is slow that could use t= he same treatment. Yit January 22, 2012