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

[Waldo Bastian]

On Wednesday 02 March 2005 23:39, 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.
>
> 2) Separate multithreaded daemons for every VFS "session" (like a ftp
> user at server combination). Like in the first case every connection would
> have it's own thread in the session daemon.
> Session data like passwords would then be kept in the "session" daemon
> process.
> This would require a "registry" daemon to manage the session daemons.
>
> IMO having single threaded "per connection" processes like KIO is
> problematic from design, because it makes access synchronization very hard:
>
> Some VFS resources will need access synchronization - editing archives
> for instance - or a FTP server which permits only one connection per
> user. In this case a "pausing - have to finish another operation"
> callback would be nice feedback.

Yes, I agree that that is a problem with KIO at the moment. That said, the 
problem is that we currently have the application manage the KIO processes, 
so we can only limit the KIO processes used by that one application. If, 
otoh, you route all requests through the central daemon, the central daemon 
will be able to handle access synchronization. So I don't think it's 
absolutely required to go for scenario 2).

That said, multiple instantations within a single VFS session probably share 
quite a bit of state info, so there are certainly benefits to that approach. 
Given that each thread will be doing more or less the same the risk of 
unexpected thread interaction isn't very big. It also opens the opportunity 
for the actual protocol backends to chose to use a single thread + a state 
machine for handling multilple jobs if they so desire.

So, yes, scenario 2) looks quite good to me.

Cheers,
Waldo
-- 
bastian at kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian at suse.com  |   http://www.novell.com/products/desktop/eval.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050303/676a115a/attachment.pgp