From owner-freebsd-hackers Fri Mar 5 10:54:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 5205E15219 for ; Fri, 5 Mar 1999 10:54:09 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 25499 invoked from network); 5 Mar 1999 18:53:49 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 5 Mar 1999 18:53:49 -0000 Received: (from toor@localhost) by y.dyson.net (8.9.1/8.9.1) id NAA00631; Fri, 5 Mar 1999 13:53:50 -0500 (EST) Message-Id: <199903051853.NAA00631@y.dyson.net> Subject: Re: lockf and kernel threads In-Reply-To: <199903050606.WAA65635@rah.star-gate.com> from Amancio Hasty at "Mar 4, 99 10:06:54 pm" To: hasty@rah.star-gate.com (Amancio Hasty) Date: Fri, 5 Mar 1999 13:53:50 -0500 (EST) Cc: dyson@iquest.net, tlambert@primenet.com, dick@tar.com, jplevyak@inktomi.com, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Amancio Hasty said: > > I supposed that for a limited distinct events signals are really cool. > > If you can deliver a signal there is nothing to stop you from delivering an > AST provided > that one can muster up the queuing delivery mechanism which is not that much > different than the beloved old fashion signal delivery mechanism. > > Does the current AIO implementation for an async call create s a thread per > call? > For raw I/O, it uses hooks into the I/O mechanisms, so it doesn't need to create threads. (Actually, close to how a realtime kernel would work.) For other I/O, it dynamically creates thread pools, and uses threads as needed. Threads don't end up being created and destroyed that often, because the requests are handled dynamically by the threads, and the threads dynamically attach/detach to the process address space. If the threads don't get used for a long time, they start disappearing. The scheme sort-of creates anonymous threads that are used as resources for multiple processes. Eventually, most of the I/O types won't have to be threaded, but the thread scheme is a concept proof of the ability to create anonymous workers in the BSD kernel. (Actually, the thread work was much more complex than the RAW I/O.) -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message