From owner-freebsd-arch Mon May 15 1:40:39 2000 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id C35CF37B5F7; Mon, 15 May 2000 01:40:26 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 12rGQF-0006te-0A; Mon, 15 May 2000 08:40:19 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA64313; Mon, 15 May 2000 09:44:41 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 15 May 2000 09:44:41 +0100 (BST) From: Doug Rabson To: Mike Smith Cc: Nick Hibma , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-Reply-To: <200005141948.MAA09452@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 14 May 2000, Mike Smith wrote: > > > > Any sense in having statically-initialised task queues? > > > > > > > > TASK_QUEUE(name); > > > > > > I thought of this but couldn't quite decide if it was useful. I don't > > > expect there to be many queues around. To start with, there will only be > > > the SWI queue. > > > > I think it is a valid point. Otherwise you might get an increased number > > of modules that require init on load. This functionality is bound to > > become very useful in cases where you want to execute things > > in a batched fashion. > > > > Apart from that, IMHO it should be > > > > TASK_QUEUE(name, enqueue_fn) > > > > to match taskqueue_init. > > Indeed. I've actually been thinking about this for a little longer, and > there are a couple of things that come to mind. > > We have a number of different callout list implementation kicking around > in the kernel at the moment; > > - the EVENTHANDLER stuff > - the optimised callout list handling in kern_timeout.c > - a few ad-hoc leftovers like config_intrhook that should have been > EVENTHANDLERed but weren't > > I don't think that kern_timeout's domain should be encroached upon, but > all of the rest of this is still worth subsuming if you're going to > produce a "better" API. > > To do that, you really only need a few extra things: > > - The ability to search for a taskqueue by name (I really don't like the > hard binding that's required by having the linker do this). > > - Some more flexibility in the enqueueing of tasks, particularly the > ability to specify a priority so that tasks on the queue are executed > in an ordered fashion. > > - Static taskqueue initialisers. > > None of these are particularly heavyweight, and they'll all end up > *reducing* bloat and complexity. I do hope to be able to replace at least some of these pieces. I like the idea of a priority sorted list of tasks, probably using a priority field in struct task. As Chuck noted, a queue name will be useful for initialising SMP mutexes so I'll add that to taskqueue_init(). It should be easy to leverage that into something like taskqueue_find(). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message