From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12138 invoked by alias); 15 Aug 2010 17:42:35 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 12127 invoked by uid 22791); 15 Aug 2010 17:42:35 -0000 X-SWARE-Spam-Status: No, hits=0.7 required=5.0 tests=BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <4C655CA0.8010205@redhat.com> References: <4C655CA0.8010205@redhat.com> Date: Sun, 15 Aug 2010 17:42:00 -0000 Message-ID: Subject: Re: Python inferior control From: Richard Ward To: Phil Muldoon Cc: archer@sourceware.org, oguzkayral@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2010-q3/txt/msg00118.txt.bz2 > On the 23rd of August 2009 Oguz Kayral submitted an initial patch to > implement GDB inferior notification events in Python. At the time I sent this (from a different email): On 24 September 2009 02:52, Richard Ward wrote: > Oguz Kayral wrote: >> >> Hi, >> This patch series adds inferior event handling support to GDB Python >> scripting. > > Hi Oguz, I've been looking forward to this functionality, Good stuff! > > I have a few comments though, if you don't mind. > > > Firstly two (fairly unimportant) things about the function registration. > > I think it would be nice if you could give upvalues to the registration > function (similar to gobject's `connect'), though admittedly it is very easy > to fake that in python using a class that defines __call__. > > Also, I'm not sure whether this would ever be an issue but it seems > advantageous to have the registration function return a unique object or > number that could subsequently be used to unregister your callable, rather > than using the callable object itself. > > > Next, in python-stopevent.c: > emit_stop_event (struct bpstats *bs, const char *stop_signal) > { > /*...snip...*/ > for (i = 0; i < PyList_Size (callback_list); i++) > { > PyObject_CallObject (PyList_GET_ITEM (callback_list, i), args_tuple); > } > } > > A couple of issues with this. First, PyObject_Callback returns a new > reference which is the return value of the function (or NULL), so it must be > handled otherwise it will leak. > > Secondly the user code may throw an exception, or the object may not be > callable. The exception should be cleared, and it would be nice to also > print the exception (PyErr_Print does both). > > Most important here though is the iteration through the list. If the user > disconnects a callback from inside a callback then the some callbacks could > be skipped. It could be better to copy the list first, but that could still > lead to some confusing behaviour, for example a callback being called after > the user thinks it ought to have been disconnected. > > Thanks, > Richard I think on reflection that copying the list is probably the sensible way to go.