Re: g_hal_volume_get_name() locking?

[Alexander Larsson <alexl redhat com>]

On Wed, 2009-01-14 at 14:32 +0100, Jannis Pohlmann wrote:
> Hey,
> 
> I'm working on porting Thunar to GIO/GVfs at the moment. When I tried
> to switch from ThunarVfsVolumeManager to GVolumeMonitor I ran into a
> locking issue but I'm not sure if it's my fault or a bug in GVfs.
> 
> Basically, what I try to do is: get the GVolumeMonitor, get a list of
> volumes, and then mount one of them using g_volume_mount() and
> g_volume_mount_finish() in the async callback. I'm using the HAL
> implementation for that and I noticed that the application simply locks
> when I try to access the internals of the GVolume in the async callback.
> 
> Here's a small test application: http://nopaste.geany.org/p/m13de531.
> It locks in line 24. When I press <Ctrl>c, I get the backtrace you'll
> find below the example code.
> 
> It seems like the lock on hal_volume is not unlocked with 
> G_UNLOCK (hal_volume) before calling the callback but I can't figure
> out why. Any ideas? It's GIO 2.18.3 and GVfs 0.2.3 by the way.

Its kinda tricky to get the hal code like that to work fine when linked
into any random app. That is why the hal volume handling was moved to be
out of process in gvfs 0.99.2, which should fix your issue.
(Incindentally it also results in less bloat and better performance
since only one process links to hal and does the probing and whatnot.)

Version 0.2.3 is pretty old btw. You should probably think about
upgrading. :)