Re: Some comments about GVFS

[Hans Petter Jansson <hpj novell com>]

On Mon, 2007-05-07 at 09:24 +0200, Alexander Larsson wrote:
> On Fri, 2007-05-04 at 17:52 +0200, Benjamin Otte wrote:

> > Yeah, I missed those implementations as I was only grepping for
> > GMainContext which you don't use.
> > I think it's a good idea to make the main context customizable so gvfs
> > can be used from other threads.

> The api used to have this, but there was a lot of overhead code carrying
> this around and adding it to the parameter list of all functions, and I
> thought there would be very very few people using it, so i killed it.
> Maybe we should discuss reverting that decision...

In Flow, I keep a GMainContext associated with each GThread. The API
user can set his own GMainContext for each thread, but for simplicity it
can only be set once, before any other Flow calls are made in that
thread.

I find that this allows for a lot of flexibility without adding much
code complexity at all:

1) The default GMainContext for the main thread is the default GLib
GMainContext. This allows sync operations to spin the main loop (so if
you have a program that lends itself to that design, you can process
redraws and UI operations while in a sync I/O call).

2) If you want hard blocking sync I/O calls, just set a different
GMainContext for the thread, and don't use it for anything else.

3) You can get at the GMainContexts used in subthreads, so you can e.g.
add your own timeouts or whatever to those.

And the best thing is, you never have to pass the GMainContexts around.
The context-per-thread management API is tiny:

http://svn.gnome.org/viewcvs/flow/trunk/flow/flow-context-mgmt.h?revision=154&view=markup

The only thing that can cause trouble is that in Flow code proper, I
have to be careful to use flow_get_main_context_for_current_thread ()
instead of g_main_context_default (). Ditto for idle and timeout
convenience functions. But I consider that minimal cost.

-- 
Hans Petter