Date: Sun, 14 May 2000 12:48:24 -0700 From: Mike Smith <msmith@freebsd.org> To: Nick Hibma <n_hibma@calcaphon.com> Cc: Doug Rabson <dfr@nlsystems.com>, arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution Message-ID: <200005141948.MAA09452@mass.cdrom.com> In-Reply-To: Your message of "Sat, 13 May 2000 15:28:35 BST." <Pine.BSF.4.20.0005131518230.76952-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005141948.MAA09452>