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

[Sean Middleditch]

On Thu, 2005-03-03 at 00:09 +0000, Jamie McCracken wrote:
>Waldo Bastian wrote:

>> 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?
>
>Well considering some of the backends would probably be synchronous in 
>nature (EG anything taht involves a lot of polling) then they would have 
>to be threaded with the deamon being async in that case - is that right?

I can't think of any situation where you have a network protocol that
must be synchronous.

Say a backend connects to the server and gets a socket.  It informs the
daemon (or application) about its socket and gives a callback, so
whenever the daemon/application mainloop detects input ready on that
socket the callback is invoked.  This callback then processes the data
in a stateful manner - once a complete request is received, the backend
generated an event that is delivered.

If the backend is loaded into the application, it can either use a plain
callback or use the app's event handling interface (all GUI apps have
one).  If the backend is in the daemon, the daemon core then marshals
the event over the connection to the application.  The application
communicates with the daemon just like it would any other network
server, but using the special D-VFS daemon protocol.  It could even be a
loadable backend itself, although I didn't plan on doing it that way.

A single thread can handle thousands of network connections.  So long as
none of the protocol handlers require huge amounts of processing time to
decode/encode events from/to the network, there should be very little
latency or throughput trouble at all.

The reason you have things like Apache worry about big complex
thread/process models is mostly due to the dynamic nature of most web
content - a browser request isn't just a simple event, its a request
that can invoke a CGI process or an in-process PHP/Perl/Java app,
database calls, authentication system calls, etc.  A single request
requires lots and lots of processing and very little actual data
transfer (relatively to the process).  If all you do is serve static web
pages, you can make a web server that's faster than Apache that uses
only a single process - you can find tons of such web servers on
Freshmeat, in fact.

Threads in apps like Nautilus are required, again, due to processing
time.  Nautilus doesn't just query the server about what files are in a
folder - it also does mime-type detection, thumbnail generation, and
other truly synchronous (or very difficult to do asynchronously)
operations.  For this reason, it's important that the D-VFS library be
usable from multiple threads in an application - and I do indeed plan on
supporting that.

>
>jamie.
>
>
>> 
>> Cheers,
>> Waldo
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> _______________________________________________
>> xdg mailing list
>> xdg at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xdg
>
>_______________________________________________
>xdg mailing list
>xdg at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/xdg
>
-- 
Sean Middleditch <elanthis at awesomeplay.com>