From owner-freebsd-arch Sun May 14 12:49:46 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.cdrom.com (adsl-63-202-176-114.dsl.snfc21.pacbell.net [63.202.176.114]) by hub.freebsd.org (Postfix) with ESMTP id AFAB137B6F8 for ; Sun, 14 May 2000 12:49:42 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA09452; Sun, 14 May 2000 12:48:24 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200005141948.MAA09452@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Nick Hibma Cc: Doug Rabson , arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution In-reply-to: Your message of "Sat, 13 May 2000 15:28:35 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 May 2000 12:48:24 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 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. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message