Re: Reverting to non-async file chooser

[Kristian Rietveld <kris imendio com>]

On Thu, Aug 24, 2006 at 01:02:51AM +0200, Tim Janik wrote:
> 
> >> there are two ways to handle this properly, in a way that doesn't need
> >> to intermix cancellation semantics with closure/memory maintenance.
> >> if your closure references an object that the callback needs, you
> >> can either forcefully keep that object alive through a reference
> >> count until the closures gets freed (which can be early enough with
> >> a high prio idler), or you set a flag in the closure/nullify the
> >> object pointer in the closure once the object becomes invalid, so the
> >> callback can tell it's not supposed to treat the reference as valid.
> >
> > This gets complicated very quickly, and requires a lot of support code.
> 
> it doesn't get complicated at all. you either explicitely ref/unref:
>    void callback_func (void *data) { g_object_unref (data); }
>    install_callback (callback_func, g_object_ref (data));
> or nullify your pointer and add a check to the callback:
>    if (!data->owner)
>      return;

I agree with Tim here; this does not require a lot of support code.
However, as with all things requiring complex reference counting,
getting it right the first time is the hardest part.

> > A scheme like GnomeVFS's requires no particular intelligence from the
> > caller.
> 
> well, the current scheme does keep it very simple on the caller:
> the notification callback is always called and just has the information
> on whether the operation was cancelled and if it succeeded or not.
> if in any particular case, cancellation also means that the caller
> has gone away, and you didn't bother setting up a nullify pointer
> handler or ref/unref pair, you can still bail out early in your
> callback with:
>    if (cancelled)
>      return;

Also, I think having only a single place where the user data of the
callback is freed is a plus of the current design.  (Obviously, we lose
this if we don't call the callback after cancellation).

> i.e. effectively render your callback inoperable, without
> introducing information loss by design.
> 
> >>>  Caveat:  gnome-vfs does not let you cancel the operation of mounting
> >>>  a drive or volume.  So if you cancel the handle from
> >>>  gtk_file_system_volume_mount(), your callback will not be called,
> >>>  but the volume *will* be mounted (unless an error occurs during
> >>>  mounting, of course).
> >>
> >> i really consider this scenrio a MUST-NOT-HAPPEN (sorry for the caps ;)
> >> simply because it renders the _combination_ of two _vital_ features
> >> unusable (unreliable), namely cancellation of operations and notification
> >> about the success of operations.

This doesn't make much sense to me; IMHO it's much better the call the
callback and have the cancelled flag set the FALSE in the handle.  Since
the volume has been mounted, the cancellation clearly failed.  We might
want to choose a different code path in the callback depending on
whether or not the operation was completed/successfully cancelled.

> but before some change like this really is decided on, could you please
> point out actual _programming_ problems you're having with the
> current scheme?
> so far, Kris has been working on fixing the remaining issues your other
> email pointed out, and hasn't complained about problems with the
> cancellation mechanism yet...

I think the current scheme should be good enough to fix the current
issues; I will continue looking it into after the weekend.



regards,

-kris.