Am Wed, 21 Jan 2009 10:26:33 +0100 schrieb 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. :) Oh, right. I didn't even think about that. I'll try a more recent version and see whether I still run into the same issue. - Jannis
Attachment:
signature.asc
Description: PGP signature