From owner-freebsd-arch Mon May 22 13:23:30 2000 Delivered-To: freebsd-arch@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id AED7237BC2B for ; Mon, 22 May 2000 13:23:20 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 12tyjA-000I5i-0B; Mon, 22 May 2000 20:23:04 +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 VAA29767; Mon, 22 May 2000 21:29:03 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 22 May 2000 21:28:45 +0100 (BST) From: Doug Rabson To: "C. Stephen Gunn" Cc: arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution (3) In-Reply-To: <20000522093218.A14101@waterspout.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 Mon, 22 May 2000, C. Stephen Gunn wrote: > On Mon, May 22, 2000 at 09:28:41AM +0100, Doug Rabson wrote: > > > The tasks called via taskqueue_free() should probably not be called at > > splhigh(). I think the right solution is to put the queue into a 'closing' > > state and return errors from taskqueue_enqueue as you suggest. > > Perhaps we should not be running the tasks at all. If we don't > care enough to clean them up at system shutdown, who cares when > a queue is going away. But, it's possible I misunderstand the > frequency of taskqueue creation and destruction in the average > system. Possibly. I was originally going to just drop the tasks on the floor but Nick Hibma suggested that I drain the queue one last time at taskqueue_free(). I don't think it really matters as long as its clearly documented what the behaviour is. > > > I'm not particularly trying to hide the task structure. The caller is > > responsible for allocating the task anyway. The intention of having a > > context value to pass to the function is flexibility. > > > > If you just pass the task pointer, then you force users to lay their > > structures out in a certain way which may not be possible in > > general. Adding a pointer to the structure is a pretty low-cost way of > > allowing the user to do anything they need. > > Couldn't you still pass the struct task so that the task_fn() could > inspect anything it might be interested in without caching a pointer? > You could still access application data just as easily from the > pointer the struct task. (or stick it at the head of another > structure, your choice). The point is that if the caller wants the task pointer, they can put that as the value of ta_context but if they want something else and we always pass the task pointer, then they are stuck. > > > > Next, I was wondering if it made any sense to put a pointer to the > > > taskqueue in the task structure. This would make it easier for > > > a task_fn() to re-queue itself. Or should we document that > > > practice as inappropriate. > > > > I thought about this and decided against it. I have some vague plans to > > extend the system to allow several queues with the same name. This > > would change taskqueue_find() to cycle through the queues round-robin > > fashion and would be used for SMP load balancing. > > That's an interesting idea. You could also multiplex these queues > on taskqueue_run() and taskqueue_enqueue(). I'm not sure that > calling taskqueue_find() for every enqueue() should be necessary. > > I'd expect to call taskqueue_find() and cache a pointer to the > queue. Which could be bad, since the queue could go away with some > areas of the kernel retaining a pointer. Hmm... There is definately some more work to do here to make something which is both useful and performs well. It would mean making taskqueue_find() scale better for lots of queues for a start. -- 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