Date: Sun, 14 May 2000 09:08:20 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Chuck Paterson <cp@bsdi.com> Cc: arch@freebsd.org Subject: Re: A new api for asynchronous task execution Message-ID: <Pine.BSF.4.21.0005140907320.47945-100000@salmon.nlsystems.com> In-Reply-To: <200005132342.RAA01739@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 13 May 2000, Chuck Paterson wrote:
>
> }
> }The system defines specific implementations of queues which are drained at
> }particular times (initially I have defined one using SWI). I want to make
> }it as easy as possible to define different lightweight queues for various
> }types of work. The 'enqueue' function pointer in the taskqueue structure
> }defines the run policy for the queue.
> }
>
> I would agree that there is no reason to change what you
> have for generic queueing. But for taskqueue_swi currently
> and a possibly others in the future you not only need to
> queue the event you want to cause a software interrupt to occur
> at the soonest reasonable time. Putting the item on the work
> queue does not seem sufficient. In particular I would argue the
> following should be avoided
>
>
> taskqueue_enqueue(struct taskqueue *queue, struct task *task)
> {
> int s = splhigh();
>
> /*
> * Count multiple enqueues.
> */
> if (task->pending) {
> task->pending++;
> return;
> }
> STAILQ_INSERT_TAIL(&queue->queue, task, link);
> task->pending = 1;
> if (queue->enqueue)
> queue->enqueue(queue);
>
> if (queueu == taskqueue_swi) <------
> setsoftaskqueue(); <------
For taskqueue_swi, this is exactly what happens in the call to
queue->enqueue(queue) above.
--
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.0005140907320.47945-100000>