From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6746 invoked by alias); 25 Feb 2003 01:37:25 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6739 invoked from network); 25 Feb 2003 01:37:23 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by 172.16.49.205 with SMTP; 25 Feb 2003 01:37:23 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 42F7CD34B6; Mon, 24 Feb 2003 17:37:22 -0800 (PST) Date: Tue, 25 Feb 2003 01:37:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: Re-initializing a list after the control returns to gdb... Message-ID: <20030225013722.GM910@gnat.com> References: <20030219020101.GI2105@gnat.com> <3E53B97A.4090809@redhat.com> <20030219175056.GP2105@gnat.com> <3E53C88E.90807@redhat.com> <20030219192422.GS2105@gnat.com> <3E53EA7A.8070001@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E53EA7A.8070001@redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2003-02/txt/msg00625.txt.bz2 [Sorry for answering late, got preempted...] > In hindsite, it needs to be converted to an observer model (or a new > observer model introduced and the current gdb-hooks changed to one of > the many observers). One model that works extremely well is the signals system implemented in glib. I find it very nicely done. It would be nice if we could reuse this, but this is a very very complex machinery doing probably way too much for what we need in GDB. I would instead suggest something much more simple, like this: enum notice_kinds { breakpoint_created_notice, breakpoint_deleted_notice, ... invalid_last_notice, /* Should always be last. */ }; typedef void (notice_ftype) (void *args, void *data); typedef void (free_notice_data) (void *data); /* Registers NOTICE_CALLBACK for notification when NOTICE_KIND events occur. Returns an id of the registration, which can be used later to unregister. DATA needs to be allocated on the heap, as it will be passed to NOTICE_CALLBACK when called. If FREE_NOTICE_DATA is not null, then this function will be called to free DATA when unsubscribing. */ int notices_subscribe (enum notice_kinds notice_kind, notice_ftype *notice_callback, void *data, void *free_notice_data); /* Equivalent of: notices_subscribe (notice_kind, notice_callback, NULL, NULL). FIXME: This is just a convenience function. Do we want to keep it? */ int notices_subscribe_no_data (enum notice_kinds notice_kind, notice_ftype *notice_callback); /* Unregister an observer. */ void notices_unsubscribe (enum notice_kinds notice_kind, int notice_id); /* Send a notice to all the observers who subscribed for the given NOTICE_KIND. ARGS is given to the notice callback who should not how to decipher it. */ void notices_send (enum notice_kinds notice_kind, void *args); The notices would be more or less implemented as an array of linked lists of observers. The DATA parameter is not strictly need in any of the forms of hooks or events that I have seen so far in GDB's code. This might prove useful in the future, but we can certainly do without. This should be fairly easy to implement, and should address all our current needs. Shall I go ahead and do that? -- Joel (who must have placed his finger at the wrong spot, all I wanted was to add a hook, but suddently I found myself swallowed in something a bit bigger :-).