From owner-freebsd-hackers Sun Feb 6 13: 0:42 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by builder.freebsd.org (Postfix) with ESMTP id C236D3DE4 for ; Sun, 6 Feb 2000 13:00:37 -0800 (PST) Received: from sol.cs.binghamton.edu (cs1-gw.cs.binghamton.edu [128.226.171.72]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with SMTP id QAA29759; Sun, 6 Feb 2000 16:01:12 -0500 (EST) Date: Sun, 6 Feb 2000 14:46:31 -0500 (EST) From: Zhihui Zhang To: freebsd-hackers@freebsd.org, arla-drinkers@stacken.kth.se Subject: Writing a multithreaded daemon process Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. Any help is appreciated. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message