From owner-freebsd-arch Sat May 13 7:22: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 D4DE537B91D for ; Sat, 13 May 2000 07:22:27 -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 IAA00701; Sat, 13 May 2000 08:22:23 -0600 (MDT) Message-Id: <200005131422.IAA00701@berserker.bsdi.com> To: Doug Rabson Cc: arch@freebsd.org Subject: Re: A new api for asynchronous task execution From: Chuck Paterson Date: Sat, 13 May 2000 08:22:23 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug, You might want to consider having a separate function/macro to enqueue on the taskqueue_swi. Instead of passing in the actual name of the task queue you would pass in some sort of flag which for now could be something like TASKQUEUE(foobar, TASKQUEUE_SWI). This would allow the lower level taskqueue_enqueue to just do the enqueueing without having to check if a software interrupt needs to be generated. For now the flag could be totally ignored, adding zero weight to what you have now. Later on, supposing that the system can support multiple interrupt threads on multiple processors, the flag could be used in a switch statement that determines which level/queue the task gets enqueued on. In a macro this code would be determined at compile time. Also it may be useful to have a flag that prevents immediate execution, ie no scheduling event, if the task is enqueued from the top half. This also is not needed at all now. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message