From owner-freebsd-arch  Sat May 13 16:42:30 2000
Delivered-To: freebsd-arch@freebsd.org
Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1])
	by hub.freebsd.org (Postfix) with ESMTP id 0F98A37B63E
	for <arch@freebsd.org>; Sat, 13 May 2000 16:42:28 -0700 (PDT)
	(envelope-from cp@berserker.bsdi.com)
Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1])
	by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id RAA01739;
	Sat, 13 May 2000 17:42:23 -0600 (MDT)
Message-Id: <200005132342.RAA01739@berserker.bsdi.com>
To: Doug Rabson <dfr@nlsystems.com>
Cc: arch@freebsd.org
Subject: Re: A new api for asynchronous task execution 
From: Chuck Paterson <cp@bsdi.com>
Date: Sat, 13 May 2000 17:42:23 -0600
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

	
}
}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();			<------
	splx(s);
}

Chuck


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message