A common VFS and a Common conf-system [Part II]
elanthis at awesomeplay.com
Thu Mar 3 00:52:58 EET 2005
On Wed, 2005-03-02 at 23:39 +0100, nf2 wrote:
>Waldo Bastian wrote:
>>On Tuesday 01 March 2005 16:48, Sean Middleditch wrote:
>>>My original idea was to *NOT* have the backends run in the library or
>>>host app itself, but instead to have a per-user daemon that handled all
>>>of the actual VFS work, and then the library would simply be an API that
>>>made it easy for an app to talk to the daemon.
>>Yes, I think this is a good approach. We may want to put some thought in
>>whether we would want to have a single-threaded daemon process, a
>>multi-threaded daemon or a single process deamon with additional worker
>I think there are only two options:
>1) A single multithreaded daemon with threads per VFS connection (like
>Gnome-VFS daemon modules). The problem with this is that a buggy VFS
>module could crash the whole VFS system.
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?
Your whole machine isn't going to be running off of this VFS - just your
desktop applications, file manager, and perhaps a few utilities.
Additionally, threading takes one of the prime advantages of a daemon -
connection sharing between different apps - and makes it a heck of a lot
more difficult, perhaps even too difficult to feasibly implement in a
stable and maintainable fashion.
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
Until you can actually show a concrete reason why a single-threaded
daemon won't work - and I highly doubt you will at all be able to do so
until after an implementation is available for testing - there is
absolutely no reason to go over-engineering the entire system with
complex threading before we even have a list of requirements or rough
API laid out. ;-)
Sean Middleditch <elanthis at awesomeplay.com>
More information about the xdg