Re: When to free GnomeVFSVolumeOpCallback?

[Alexander Larsson <alexl redhat com>]

On Tue, 2004-07-27 at 18:09, Torsten Schoenfeld wrote:
> Aloha,
> 
> I'm in the process of wrapping the GnomeVFSDrive and GnomeVFSVolume API
> for Perl (better late than never), and I'm wondering how to know when
> the callbacks for
> 
>   gnome_vfs_drive_mount, _umount, _eject and
>   gnome_vfs_volume_unmount, _eject
> 
> will no longer be called and can be safely freed.  From the looks of it
> the code first spawns a thread which spawns an external command to do
> the job and then installs an idle handler which finally calls the
> callback.
> 
> One way to do it is to put a reference to every callback structure into
> the GObject so that they get destroyed when the drive/volume is
> finalized.  That doesn't seem optimal, though.

No, thats not right. The callback doesn't have a ref on the
drive/volume, so that can go away before the callback is called.

> So, is there another way to safely free the callbacks?

I'm not sure exactly what the problem is. Once you've called
gnome_vfs_drive_mount you can't free the callback structure you passed
in until you've gotten the callback. Even if the mount failed you will
get the callback. There should be no way to "leak" the structure.

Why can't you just add a ref to the callback structure before calling
gnome_vfs_drive_mount, and unref it in your callback handler?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a leather-clad crooked grifter She's an enchanted punk college professor 
from a family of eight older brothers. They fight crime!