From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2093 invoked by alias); 13 Aug 2010 19:49:54 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 2082 invoked by uid 22791); 13 Aug 2010 19:49:53 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org From: Tom Tromey To: Phil Muldoon Cc: archer@sourceware.org, oguzkayral@gmail.com Subject: Re: Python inferior control References: <4C655CA0.8010205@redhat.com> Date: Fri, 13 Aug 2010 19:49:00 -0000 In-Reply-To: <4C655CA0.8010205@redhat.com> (Phil Muldoon's message of "Fri, 13 Aug 2010 15:54:24 +0100") 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-SW-Source: 2010-q3/txt/msg00112.txt.bz2 >>>>> "Phil" == Phil Muldoon writes: Phil> I've not changed very much: renamed the files, re-ordered the Phil> Makefile.in and made some minor code changes so that it compiles. Thanks for doing this. I skimmed through it. Some of the formatting is weird, maybe due to wrapping in the original posts? Anyway, be sure to fix all that up. It still seems like a lot of code to define a new event. But I think we will just live with that. Or maybe there is some way to reduce its size, through macros or something. There seems to be a fair amount of boilerplate. There are places where the error-checking is not correct. E.g., emit_breakpoint_stop_event calls PyObject_CallObject but does not check its return value. (FWIW I think that errors in events should be reported and then ignored -- not propagate.) I see new attributes like "stop_eventregistry". I think we should drop the "registry" part of these names. I see that all the existing event registries are on the Thread object. I think this is fine, but I think we will also want to add more. In particular: * We want some way to determine that the entire inferior has exited. * It seems logical to want to be able to put an event handler on a breakpoint, to notice when that breakpoint is hit. There are probably more of these. I don't mind if we add them as needed -- but it would be nice if the first release incorporating the event machinery were complete enough to enable some "nice" scripts. I am not sure about all of the logic in emit_stop_event. Is this a full enumeration of stop reasons? Also I am unsure about python_thread_exit. Looking at $_exitcode seems strange -- a thread doesn't really have an exit code, only the inferior as a whole does. One place to look for ideas here is how MI does it... I'm afraid there will probably be more things once the above are fixed up. Due to the formatting and lack of docs, this patch was sort of difficult to read. But, I think the basics are ok. Tom