A common VFS and a Common conf-system [Part II]
elanthis at awesomeplay.com
Thu Mar 3 02:38:17 EET 2005
On Thu, 2005-03-03 at 00:30 +0100, Waldo Bastian wrote:
>On Wednesday 02 March 2005 23:52, Sean Middleditch wrote:
>> Why would the daemon even need to be threaded at all? What advantages
>> in *concrete* terms do you hope to solve with a threaded daemon that
>> couldn't be done just a well with a single-threaded daemon?
>> The daemon is not going to be doing any kind of heavy processing. It's
>> just a way to marshal calls to backends through a single process to
>> facilitate connection sharing, easing the implementation of change
>> polling and similar features, and provide the opportunity to control
>> data flow and authentication requests in an
>> SELinux/TrustedBSD/TrustedSolaris-friendly way.
>I think there is some misunderstanding here about the separation between
>daemon and the backends. The question isn't so much about the daemon itself,
>as well as how the backends run. Do the backends run in a process of
>themselve, as separate thread in the daemon process or do they time-share the
>main single thread of the daemon?
The backends are just shared libraries that are loaded into the daemon
(or application). The backends are really just event dispatchers and
receivers - you can run the entire thing off of a poll() loop (or kqueue
or epoll for higher efficiency if available). The daemon core is just
an event broker, similar to D-BUS but far simpler and more specialized.
(The original plan I started cooking up a couple months ago actually
used D-BUS here.)
This also makes it possible to use the same backend either in the daemon
or in the application process itself - whichever the administrator feels
is more appropriate. (For example, I see no reason to marshal calls to
the file: protocol handler through the daemon.)
Are there any protocol backends you know of that are very difficult to
implement without using threads?
>xdg mailing list
>xdg at lists.freedesktop.org
Sean Middleditch <elanthis at awesomeplay.com>
More information about the xdg