[patch] remove DBusGPendingCall
hp at redhat.com
Thu Jul 7 07:04:42 EST 2005
On Wed, 2005-07-06 at 11:06 -0400, Colin Walters wrote:
> On Wed, 2005-07-06 at 01:37 -0400, Havoc Pennington wrote:
> > My basic take on guint IDs in GLib is that they are crackrock - more
> > recent APIs support this view with e.g. GSource* replacing the old ID
> > API.
> Actually as far as I can see GSource * is used when you want to attach
> to non-default mainloops, it doesn't really replace the ID API.
> Functions using GSource still return guint, e.g.:
> guint g_source_attach (GSource *source,
> GMainContext *context);
I think this is basically just back compat noise though. It isn't useful
in any way that I know of.
> However I see your point, and it is a good one.
> The trick GnomeVFS does is to expose what looks like a structure pointer
> in the API, but is actually just a guint internally. So that's what
> I've done as well.
I generally agree with Ray on the "why?" question ;-) (having the guint
indirection seems like more work/complexity) but sure, as you say we can
clean it up later.
> > - inefficiency due to the hash table vs.
> > just pointer deref
> True, but I'm fairly certain that one hash table lookup is not the
> efficiency bottleneck in the GLib bindings. I've just been waiting
> until someone complains and identifies specific areas before I work on
I doubt this does matter in this case, I'm just making a general point.
I think it matters in the libgobject case unfortunately. All the use of
IDs instead of pointers in libgobject is kind of lame.
> I don't think they do but it should be easy enough to fix. I think just
> one more conditional in proxy_register. I'll add this to TODO.
> Thanks for the comments. How about this patch?
More information about the dbus