Date: Fri, 5 Mar 1999 13:53:50 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: dyson@iquest.net, tlambert@primenet.com, dick@tar.com, jplevyak@inktomi.com, hackers@FreeBSD.ORG Subject: Re: lockf and kernel threads Message-ID: <199903051853.NAA00631@y.dyson.net> In-Reply-To: <199903050606.WAA65635@rah.star-gate.com> from Amancio Hasty at "Mar 4, 99 10:06:54 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903051853.NAA00631>