From owner-freebsd-usb@FreeBSD.ORG Mon Nov 8 16:44:11 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFFAB106564A; Mon, 8 Nov 2010 16:44:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9BB2D8FC0C; Mon, 8 Nov 2010 16:44:10 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1250E46B35; Mon, 8 Nov 2010 11:44:10 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0F2B58A009; Mon, 8 Nov 2010 11:44:09 -0500 (EST) From: John Baldwin To: Matthew Fleming Date: Mon, 8 Nov 2010 11:42:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201011012054.59551.hselasky@c2i.net> <201011080947.00550.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011081142.46175.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 08 Nov 2010 11:44:09 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-usb@freebsd.org, Weongyo Jeong , freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 16:44:11 -0000 On Monday, November 08, 2010 10:34:33 am Matthew Fleming wrote: > On Mon, Nov 8, 2010 at 6:47 AM, John Baldwin wrote: > > On Saturday, November 06, 2010 4:33:17 pm Matthew Fleming wrote: > >> On Sat, Nov 6, 2010 at 7:22 AM, Hans Petter Selasky wrote: > >> > Hi, > >> > > >> > On Saturday 06 November 2010 14:57:50 Matthew Fleming wrote: > >> >> > >> >> I think you're misunderstanding the existing taskqueue(9) implementation. > >> >> > >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot change, > >> >> nor can the set of running tasks. So the order of checks is > >> >> irrelevant. > >> > > >> > I agree that the order of checks is not important. That is not the problem. > >> > > >> > Cut & paste from suggested taskqueue patch from Fleming: > >> > > >> > > +int > >> >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) > >> >> > +{ > >> >> > + int rc; > >> >> > + > >> >> > + TQ_LOCK(queue); > >> >> > + if (!task_is_running(queue, task)) { > >> >> > + if ((rc = task->ta_pending) > 0) > >> >> > + STAILQ_REMOVE(&queue->tq_queue, task, task, > >> >> > ta_link); + task->ta_pending = 0; > >> >> > + } else { > >> >> > + rc = -EBUSY; > >> > > >> > What happens in this case if ta_pending > 0. Are you saying this is not > >> > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE() ? > >> > >> Ah! I see what you mean. > >> > >> I'm not quite sure what the best thing to do here is; I agree it would > >> be nice if taskqueue_cancel(9) dequeued the task, but I believe it > >> also needs to indicate that the task is currently running. I guess > >> the best thing would be to return the old pending count by reference > >> parameter, and 0 or EBUSY to also indicate if there is a task > >> currently running. > >> > >> Adding jhb@ to this mail since he has good thoughts on interfacing. > > > > I agree we should always dequeue when possible. I think it should return > > -EBUSY in that case. That way code that uses 'cancel' followed by a > > conditional 'drain' to implement a blocking 'cancel' will DTRT. > > Do we not also want the old ta_pending to be returned? In the case > where a task is pending and is also currently running (admittedly a > narrow window), how would we do this? This is why I suggested > returning the old ta_pending by reference. This also allows callers > who don't care about the old pending to pass NULL and ignore it. I would be fine with that then. I wonder if taskqueue_cancel() could then return a simple true/false. False if the task is running, and true otherwise? -- John Baldwin