Re: gdbus branch review

[Tomas Bzatek <tbzatek redhat com>]

Alright, with Alex's blessing I've merged the first part of GDBus port
and made 1.13.1 release. Under normal circumstances no difference should
be observed. Please report any issues or inconsistencies.

The core port is slowly evolving in the 'gdbus-core' branch yet it still
needs some work to be fully functional. Most of the functionality is
there and the major things to solve are cancellation and progress
callback.

-- 
Tomas Bzatek <tbzatek redhat com>


On Thu, 2012-05-31 at 15:13 +0200, Tomas Bzatek wrote:
> On Thu, 2012-05-24 at 10:12 +0200, Alexander Larsson wrote:
> > Really? Why not create it in the GVfs initializer? That should be
> > protected by a lock already. Or if you want to do it lazily, use a
> > g_once_init_* thing?
> 
> I would still like to retain the on-demand behaviour. Since the metadata
> proxy is only used for three calls, I don't want to create it every time
> GDaemonVfs or GDaemonFile is used.
> 
> Using g_bus_watch_name_on_connection() and its handlers for proxy
> creation and destruction would be a good way unless we need it
> immediately. There might not be a chance for proxy creation between
> g_daemon_vfs_class_init() and the call demanding the proxy as long as
> callbacks are async.
> 
> > I worry a bit about the GPrivate use with
> > g_bus_watch_name_on_connection(). On which thread is the
> > metadata_daemon_vanished callback called? Are we guaranteed that it'll
> > be on the thread that had the GPrivate? That seems unlikely as it might
> > not even run a mainloop...
> 
> Ok, GPrivate turned to be hard manageable with the current tools if you
> want to be able to clean it by multiple events. Same thing we're facing
> in bug 676825.
> 
> So I went for the dumb-most solution and used a static proxy instance
> surrounded by locks. Haven't committed the changes yet, attaching for
> review as I have a feeling I'll rework the patch once more.
> 
> 
> > If you don't flush, then a commandline invocation like gvfs-copy will
> > exit with the dbus outgoing message queue non-empty, and we will thus
> > lose the metadata change. I agree that a flush might be unnecessarily
> > costly though. Not sure what the best approach is here. Maybe GDBus
> > could do a flush in an atexit handler? Or maybe the gvfs commandline
> > utils should ensure flushing on exit?
> 
> I don't really like adding workarounds to client apps due to our
> imperfection. Looking at the impact as a whole, these two affected
> functions are called from GLocalFile side only and there don't
> necessarily need to be other traffic generated by other GIO calls. I've
> added a sync flush to be on the safe side:
> http://git.gnome.org/browse/gvfs/commit/?h=gdbus&id=a541205d83d7a66cb37d2c797aa78a0e258fc4e6
> 
> 
> Btw. searching through the code, I couldn't find moved()/removed()
> counterparts for GVfs mounts. Since we're storing metadata even for GVfs
> mounts, there should be a mechanism to update the db for these
> operations. How's that done?
> 
> _______________________________________________
> gvfs-list mailing list
> gvfs-list gnome org
> https://mail.gnome.org/mailman/listinfo/gvfs-list