Writing a multithreaded daemon process

[Nathan Neulinger]

Zhihui Zhang wrote:
> 
> After reading part of the Arla daemon code available at
> http://www.stacken.kth.se/projekt/arla/, I feel it is a real good design.
> The daemon code is a multi-threaded user process that does most of the job
> and the kernel is an interface to VFS. They communicate with each other
> via a character device.
> 
> But I am wondering if the performance is good since you sometimes have to
> cross user-system boundary up to four times for a single read operations:
> 
>  read() --> Arla daemon --> network  --> install data into kernel
> 
> If the daemon can somehow reside entirely inside the kernel, like NFS
> daemon, we can save those crossings.  But the daemon is a multi-threaded
> process and we have no kernel thread yet, so I do not know how to do
> better if possible.  Maybe all user filesystems have to live with this
> limitation.

I believe that you could do this reasonably if you got rid of the cache,
or used a low level block device directly as the cache. The problem is -
kernel processes don't necessarily have any user space access (i.e.
getting to filesystems). 

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul at umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
CIS - Systems Programming                Fax: (573) 341-4216