Date: Thu, 4 Nov 2010 13:11:38 -0700 From: Matthew Fleming <mdf356@gmail.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org, Weongyo Jeong <weongyo.jeong@gmail.com> Subject: Re: [RFC] Outline of USB process integration in the kernel taskqueue system Message-ID: <AANLkTinoUKy6P=U7q9qEKvEviw1Z_rxvdBvUotuGuTzi@mail.gmail.com> In-Reply-To: <201011042011.44705.hselasky@c2i.net> References: <201011012054.59551.hselasky@c2i.net> <201011041941.09662.hselasky@c2i.net> <AANLkTin3Zp82KDJiunS1A1Wf3bSeWGFxh8wTc4Gu6551@mail.gmail.com> <201011042011.44705.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 4, 2010 at 12:11 PM, Hans Petter Selasky <hselasky@c2i.net> wro= te: > On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: >> On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky <hselasky@c2i.net> > wrote: >> > On Thursday 04 November 2010 15:29:51 John Baldwin wrote: >> >> =A0(and there is in Jeff's OFED branch) >> > >> > Is there a link to this branch? I would certainly have a look at his w= ork >> > and re-base my patch. >> >> It's on svn.freebsd.org: >> >> http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_task= que >> ue.c?view=3Dlog >> http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D209422 >> >> For the purpose of speed, I'm not opposed to breaking the KBI by using >> a doubly-linked TAILQ, but I don't think the difference will matter >> all that often (perhaps I'm wrong and some taskqueues have dozens of >> pending tasks?) >> >> Thanks, >> matthew > > At first look I see that I need a non-blocking version of: > > taskqueue_cancel( > > At the point in the code where these functions are called I cannot block.= Is > this impossible to implement? It depends on whether the queue uses a MTX_SPIN or MTX_DEF. It is not possible to determine whether a task is running without taking the taskqueue lock. And it is certainly impossible to dequeue a task without the lock that was used to enqueue it. However, a variant that dequeued if the task was still pending, and returned failure otherwise (rather than sleeping) is definitely possible. Thanks, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinoUKy6P=U7q9qEKvEviw1Z_rxvdBvUotuGuTzi>