From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23171 invoked by alias); 18 Oct 2011 13:41:31 -0000 Received: (qmail 23163 invoked by uid 22791); 18 Oct 2011 13:41:30 -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 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; Tue, 18 Oct 2011 13:41:02 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9IDf1Yg026959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Oct 2011 09:41:02 -0400 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p9IDevuj003466; Tue, 18 Oct 2011 09:40:58 -0400 From: Phil Muldoon To: Kevin Pouget Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [Python - doc] gdb.post_event description References: Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Tue, 18 Oct 2011 13:58:00 -0000 In-Reply-To: (Kevin Pouget's message of "Tue, 18 Oct 2011 13:56:48 +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/msg00499.txt.bz2 Kevin Pouget writes: > On Fri, Oct 14, 2011 at 9:48 PM, Tom Tromey wrote: >>>>>>> "Kevin" == Kevin Pouget writes: >> >> Kevin> according to my experimentations, gdb_do_one_event, which (indirectly) >> Kevin> triggers the processing of Python events posted with gdb.post_event, >> Kevin> is executed right after the prompt has been displayed (and new >> Kevin> charactered fed in), and nowhere else (as far as I could investigate). >> >> Kevin> Does it look right to you? >> >> Yeah, but I would not want to document this too precisely; it is good, I >> think, to have some leeway so we can run the event queue at other times >> if we find the need in the future. > > sure, > > but I think that the notion of "event" is quite vague here, for > instance we've got Python events, which are totally unrelated to > "post_event" (as far as I understood); and internally there are > inferior events. > (Actually, with that knowledge, I expected 'post_event' events to be > processed more often). > > So I think it's important to state when the callback will be > triggered, give the prompt as an example, and mentioned that more > event processing points might be added in the next releases > > What do you think about it? Sorry I did not see this until now. The problem is that events are processed in GDB (I believe) at different times, in different parts of the code, and more importantly are subject to change. So if we document "blah event will be processed after foo operation", then there is an expectation is that it will also be so. We have exposed an internal mechanic of GDB and cast it in an API promise. We cannot live-up to that expectation. Nor should we, imo, imply any guarantee when the event will be processed other than it will. Cheers, Phil