Date: Mon, 22 May 2000 09:32:18 -0500 From: "C. Stephen Gunn" <csg@waterspout.com> To: Doug Rabson <dfr@nlsystems.com> Cc: arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution (3) Message-ID: <20000522093218.A14101@waterspout.com> In-Reply-To: <Pine.BSF.4.21.0005220919420.73457-100000@salmon.nlsystems.com>; from dfr@nlsystems.com on Mon, May 22, 2000 at 09:28:41AM %2B0100 References: <20000521123546.A7522@waterspout.com> <Pine.BSF.4.21.0005220919420.73457-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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). > > 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... - Steve 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?20000522093218.A14101>