GNOME.org
 

Re: Plans for gnome-vfs replacement

On Mon, 25 Sep 2006, Alexander Larsson wrote:


On Mon, 2006-09-25 at 12:04 +0200, Tim Janik wrote:

On Wed, 20 Sep 2006, Alexander Larsson wrote:


On Wed, 2006-09-20 at 14:30 +0200, mathieu lacage wrote:



2) What is the signature of GDestroyNotify ?


Its already in gtypes.h:
typedef void            (*GDestroyNotify)       (gpointer       data);


ah. I forgot about this. Don't you think it might make sense for ease of
use to add a void *buffer arg and a GOutputStream * arg to the destroy
notification ?


Nah, In typical real world cases these would already be in the user_data
object. Say if you're reading a whole file async. It feels better to
keep to the standard glib destroy notifier handling.


i have to agree with Mathieu here. not passing the original object handle
forces the user to keep tedious etxra data structures around.
imagine:
struct UserObject {
   GOutputStream *stream1;
   GOutputStream *stream2;
};

naturally, you'd pass UserObject* as gpointer data to the stream.
if your notifiers don't also contain the GOutputStream* handle though,
the user can't clearly identify stream1 vs. stream2 though, so he'd have to
resort to creating helper structures:
struct UserObjectOutputStreamCallbackData {
   UserObject    *user_object;
   GOutputStream *stream:
};
and allocate/pass/free this instead.


The actual operation callback for an async operation does of course pass
both the stream and the user data. And it is always called, even on
cancellation, so the destroy notifier isn't required. The destroy
notifier is more of an extra freebie to make it simple to add a g_free
or g_object_unref to free the user object. For a more complicated
multi-stream setup I think you'd do the handling in the operation
callbacks.


ah i see, that makes sense, as far as the operation callback is
concerned at least.


Also, In your example above the extra structure isn't needed. One would
just use different destroy notifiers for the two streams.


hm, different? you mean you'd encode whether it's stream1 or stream2 in
the destroy notifier callback implementation?
well, that breaks as soon as the user has a non-fixed number:
struct UserObject {
  guint           n_streams;
  GOutputStream **streams;
};

as an anecdotal side note, one case where i originally went for just
having a single data argument in the destroy notifier, and later had
to extend the callback signature to also cover the original object due
to user requests was GWeakNotify.
in your case, i think it's pretty forseeable that passing the object
handle along with the destroy notifier _can_ be useful and is easy to
implement on the caller side. if it's lacking, it's really tedious to
substitute on the user side though, so it'd be best to go with a signature
like that of GWeakNotify from the start.


(not providing GOutputStream, but just data, would be a bit like eliminating
the instance argument from signal handlers and force people to pass it along
as part of the user_data passed in to g_signal_connect() ;)


I don't think so. I.e. for an aync read the callback would look like:

typedef void (*GAsyncReadCallback)  (GInputStream *stream,
				     void              *buffer,
				     gsize              count_requested,
				     gsize              count_read,
				     gpointer           data,
				     GError            *error);

This callback is similar to the signal handler. The destroy notifier is
just gravy on top of it.

If we're stretching our comparisons a bit here it would be more like
having the GDestroyNotifier called for a hashtable entry also pass a
pointer to the hashtable so that you can destroy the entry differently
depending on which hashtable it was in. :)


ok, i buy that one. ;)
and frankly, if i were to review the addition of destroy notifiers to
the hash table API *these* days, i'd insist on passing the hash table
along, similar to the instance in GWeakNotify ;)


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson                                            Red Hat, Inc
                  alexl redhat com    alla lysator liu se


---
ciaoTJ
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]