Date: Mon, 22 May 2000 09:28:41 +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.0005220919420.73457-100000@salmon.nlsystems.com> In-Reply-To: <20000521123546.A7522@waterspout.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 May 2000, C. Stephen Gunn wrote: > > Doug & -arch, > > First let me say that your taskqueue stuff looks great. In looking > over the API, and your implementation, I have some questions. > > First, as someone else already pointed out, you were calling the > tasks at splhigh(). While you fixed this in taskqueue_run(), the > call to taskqueue_run() inside taskqueue_free() runs at splhigh(). > This is probably intended to avoid new tasks being queued by > interrupt handlers while disposing of the queue. > > What about an intelligent (or stupid) task that tries to queue > itself onto the queue again? This isn't an uncommon mechanism for > periodic tasks. > > Having taskqueue_enqueue() return an error if we're in the process > of deleting this queue could address this problem. It's a rare > case, since I don't foresee the creation/deletion of queues happening > with much frequency. 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. > > I was also wondering about the ta_context mechanism. I initially > thought you were trying to hide the task structure behind the API > so that binary-only modules (and the like) would be tolerant of > changes in the structure. This is probably not the case, since > task_enqueue() takes a struct *task. > > Would there be any benefit to simply passing the task structure to > the task_fn()? > > Tasks could then define a struct with a struct task at the top. > This mechanism is certainly used lots of placed in the kernel. > I know there's little real difference. I guess my questions is > whether the rest of the kernel sets any precident. I'm not particularly trying to hide the task structure. The caller is reponsible 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. > > 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 doucment 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. > > Finally, are you planning to call taskqueue_free() on all the queues > at system shutdown? This is obviously outside the scope of the > code you'd provided, I was just wondering. Probably not. -- 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.0005220919420.73457-100000>