Re: [RFC] Outline of USB process integration in the kernel taskqueue system

On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote:
> On Thursday 04 November 2010 21:11:38 Matthew Fleming wrote:
> > On Thu, Nov 4, 2010 at 12:11 PM, Hans Petter Selasky <hselasky_at_c2i.net> 
> wrote:
> > > On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote:
> > >> On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky <hselasky_at_c2i.net>
> > > 
> > > wrote:
> > >> > On Thursday 04 November 2010 15:29:51 John Baldwin wrote:
> > >> >>  (and there is in Jeff's OFED branch)
> > >> > 
> > >> > Is there a link to this branch? I would certainly have a look at his
> > >> > work 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=log
> > >> http://svn.freebsd.org/viewvc/base?view=revision&revision=209422
> > >> 
> > >> 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.
> 
> I think that if a task is currently executing, then there should be a drain 
> method for that. I.E. two methods: One to stop and one to cancel/drain. Can 
> you implement this?

I agree, this would also be consistent with the callout_*() API if you had
both "stop()" and "drain()" methods.

-- 
John Baldwin