From owner-freebsd-arch Sun May 21 10:32: 1 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dustdevil.waterspout.com (standpipe.waterspout.com [208.13.60.152]) by hub.freebsd.org (Postfix) with ESMTP id 2640537B90A for ; Sun, 21 May 2000 10:31:58 -0700 (PDT) (envelope-from csg@dustdevil.waterspout.com) Received: (from csg@localhost) by dustdevil.waterspout.com (8.9.3/8.9.3) id MAA07682; Sun, 21 May 2000 12:35:46 -0500 (EST) (envelope-from csg) Date: Sun, 21 May 2000 12:35:46 -0500 From: "C. Stephen Gunn" To: Doug Rabson Cc: arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution (3) Message-ID: <20000521123546.A7522@waterspout.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from dfr@nlsystems.com on Thu, May 18, 2000 at 09:24:13PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. 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. 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. 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. - Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message