From owner-freebsd-usb@FreeBSD.ORG Mon Nov 8 17:04:57 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 DB2A1106564A; Mon, 8 Nov 2010 17:04:57 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7E58FC1D; Mon, 8 Nov 2010 17:04:57 +0000 (UTC) Received: by pxi1 with SMTP id 1so1067896pxi.13 for ; Mon, 08 Nov 2010 09:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IMsU0iLLKZy4M0mTial+VDi0L/cNT9Zi3iPWW1QsgJc=; b=mr1oWxGvvUW4yJDDLgR1FTgfiNfmsZZO5/JshKAkYGPblZxo9Zh9pXHkbl6sO5PVQs W0X1RjaDdHGz1RU43pKvaoK+Ym+TRLUXRcc2Dv7L+sKC275FLOAj/zfHoDvbXuhYpsOY oFiNTLGs3AitH1hnF1Yk2MqyOYSQDsrB7Y+RU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=g4PxTTL5VgTQMgwcSJvjADKX5bDc51bPhxWMGxrUx1Gh4dOQFiBRF/vxURoaKE+SWa cCewxnWVoopAgRLU9tK143nQSPCGGnnxDMM4Dpk9d8u9cHlQBkokJXcOkgScFPbKd3cx GLaIJHlxl1ASC8uhDKuR2wuKjvIJ8yTkpaXKo= MIME-Version: 1.0 Received: by 10.42.165.200 with SMTP id l8mr2253305icy.326.1289235894985; Mon, 08 Nov 2010 09:04:54 -0800 (PST) Received: by 10.231.21.35 with HTTP; Mon, 8 Nov 2010 09:04:54 -0800 (PST) In-Reply-To: References: <201011012054.59551.hselasky@c2i.net> <201011080947.00550.jhb@freebsd.org> <201011081142.46175.jhb@freebsd.org> Date: Mon, 8 Nov 2010 09:04:54 -0800 Message-ID: From: Matthew Fleming To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 17:04:58 -0000 On Mon, Nov 8, 2010 at 8:46 AM, Matthew Fleming wrote: > On Mon, Nov 8, 2010 at 8:42 AM, John Baldwin wrote: >> 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) impleme= ntation. >>> >> >> >>> >> >> As long as TQ_LOCK is held, the state of ta->ta_pending cannot ch= ange, >>> >> >> nor can the set of running tasks. =A0So 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: >>> >> > >>> >> > =A0> +int >>> >> >> > +taskqueue_cancel(struct taskqueue *queue, struct task *task) >>> >> >> > +{ >>> >> >> > + =A0 =A0 =A0 int rc; >>> >> >> > + >>> >> >> > + =A0 =A0 =A0 TQ_LOCK(queue); >>> >> >> > + =A0 =A0 =A0 if (!task_is_running(queue, task)) { >>> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((rc =3D task->ta_pending) > 0= ) >>> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 STAILQ_REMOVE(&qu= eue->tq_queue, task, task, >>> >> >> > ta_link); + =A0 =A0 =A0 =A0 =A0 =A0 =A0 task->ta_pending =3D 0; >>> >> >> > + =A0 =A0 =A0 } else { >>> >> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 rc =3D -EBUSY; >>> >> > >>> >> > What happens in this case if ta_pending > 0. Are you saying this i= s not >>> >> > possible? If ta_pending > 0, shouldn't we also do a STAILQ_REMOVE(= ) ? >>> >> >>> >> Ah! =A0I see what you mean. >>> >> >>> >> I'm not quite sure what the best thing to do here is; I agree it wou= ld >>> >> be nice if taskqueue_cancel(9) dequeued the task, but I believe it >>> >> also needs to indicate that the task is currently running. =A0I gues= s >>> >> 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. =A0I think it should = return >>> > -EBUSY in that case. =A0That 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? =A0In the case >>> where a task is pending and is also currently running (admittedly a >>> narrow window), how would we do this? =A0This is why I suggested >>> returning the old ta_pending by reference. =A0This also allows callers >>> who don't care about the old pending to pass NULL and ignore it. >> >> I would be fine with that then. =A0I wonder if taskqueue_cancel() could = then >> return a simple true/false. =A0False if the task is running, and true >> otherwise? > > Sure, though since we don't really have a bool type in the kernel I'd > still prefer to return an int with EBUSY meaning a task was running. I'll commit this later today unless there are objections. http://people.freebsd.org/~mdf/0001-Add-a-taskqueue_cancel-9-to-cancel-a-pe= nding-task-wi.patch Thanks, matthew