This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re-initializing a list after the control returns to gdb...


[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 :-). 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]