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/ _______________________________________________ gconf-list mailing list gconf-list@gnome.org http://mail.gnome.org/mailman/listinfo/gconf-list