From owner-freebsd-arch Mon May 22 7:28:59 2000 Delivered-To: freebsd-arch@freebsd.org Received: from dustdevil.waterspout.com (fourier.physics.purdue.edu [128.210.146.43]) by hub.freebsd.org (Postfix) with ESMTP id 6550437B98D for ; Mon, 22 May 2000 07:28:51 -0700 (PDT) (envelope-from csg@dustdevil.waterspout.com) Received: (from csg@localhost) by dustdevil.waterspout.com (8.9.3/8.9.3) id JAA14163; Mon, 22 May 2000 09:32:18 -0500 (EST) (envelope-from csg) Date: Mon, 22 May 2000 09:32:18 -0500 From: "C. Stephen Gunn" To: Doug Rabson Cc: arch@FreeBSD.ORG Subject: Re: A new api for asynchronous task execution (3) Message-ID: <20000522093218.A14101@waterspout.com> References: <20000521123546.A7522@waterspout.com> 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 Mon, May 22, 2000 at 09:28:41AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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