Date: Mon, 22 May 2000 21:28:45 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: "C. Stephen Gunn" <csg@waterspout.com> Cc: arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution (3) Message-ID: <Pine.BSF.4.21.0005222104320.73457-100000@salmon.nlsystems.com> In-Reply-To: <20000522093218.A14101@waterspout.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0005222104320.73457-100000>