Re: The new markup-tree stuff

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2005-06-09 at 20:13 +0200, Philip Van Hoof wrote:

> > We could fix this by preloading some typical paths. Or by making
> > markup-tree.c thread-safe and launch a pool of worker threads that 
> > will do the reading of paths (and g_idle the GMainLoop about when
> > such a file is read, so that it can inform the client etcetera). But
> > thats just an idea of course.

> Hmm, no. It will have to be done by making the ORBit-2 server
> multithreaded (ORBIT_THREAD_HINT_PER_REQUEST).
> 
> Which basically means that most parts of GConf needs to become
> thread-safe. 

We (behdad and me) have been thinking about using aio_read and aio_error
to solve this.

Something like this:

- Make the ORBit-2 ORBIT_THREAD_HINT_PER_REQUEST (so that multiple
requests in parallel are now possible)

- Let the request-thread wait for a per-request status (the rest of
gconfd isn't thread-safe and designing it that way basically means a
complete rewrite -- we'll do that with dconf --)

- If the result is cached (markup-tree) immediately return it

- Else aio_read the result and let the mainthread check for
(aio_error(..) == 0). If it is 0, start the parsing in the cache and set
the status of the request to finished. The thread will return the result
from the cache.


Now the reading of the persistent data is asynchronous. The daemon won't
block (ORBIT_THREAD_HINT_PER_REQUEST) yet it's not expecting a
thread-safe design of the daemon.

Thoughts?


-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.pvanhoof.be/