[RFC] Outline of USB process integration in the kernel
taskqueue system
John Baldwin
jhb at freebsd.org
Fri Nov 5 19:07:56 UTC 2010
On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote:
> On Friday 05 November 2010 19:48:05 Matthew Fleming wrote:
> > On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky <hselasky at c2i.net>
> wrote:
> > > On Friday 05 November 2010 19:39:45 Matthew Fleming wrote:
> > >> True, but no taskqueue(9) code can handle that. Only the caller can
> > >> prevent a task from becoming enqueued again. The same issue exists
> > >> with taskqueue_drain().
> > >
> > > I find that strange, because that means if I queue a task again while it
> > > is running, then I doesn't get run? Are you really sure?
> >
> > If a task is currently running when enqueued, the task struct will be
> > re-enqueued to the taskqueue. When that task comes up as the head of
> > the queue, it will be run again.
>
> Right, and the taskqueue_cancel has to cancel in that state to, but it doesn't
> because it only checks pending if !running() :-) ??
You can't close that race in taskqueue_cancel(). You have to manage that
race yourself in your task handler. For the callout(9) API we are only
able to close that race if you use callout_init_mtx() so that the code
managing the callout wheel can make use of your lock to resolve the races.
If you use callout_init() you have to explicitly manage these races in your
callout handler.
--
John Baldwin
More information about the freebsd-usb
mailing list