A common VFS and a Common conf-system [Part II]

[Sean Middleditch]

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 
>>processes.
>>
>>  
>>
>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
SELinux/TrustedBSD/TrustedSolaris-friendly way.

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>