Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 May 2000 17:42:23 -0600
From:      Chuck Paterson <cp@bsdi.com>
To:        Doug Rabson <dfr@nlsystems.com>
Cc:        arch@freebsd.org
Subject:   Re: A new api for asynchronous task execution 
Message-ID:  <200005132342.RAA01739@berserker.bsdi.com>

next in thread | raw e-mail | index | archive | help
	
}
}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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005132342.RAA01739>