Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Jul 2015 19:52:56 -0400
From:      Ryan Stone <rysto32@gmail.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        Jack Vogel <jfvogel@gmail.com>, FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: How should a driver shutdown a taskqueue on detach?
Message-ID:  <CAFMmRNxGqdmrfLc3U9BW4BWzM_PxN0NO0i0NNrbC_Qsgf=2wUw@mail.gmail.com>
In-Reply-To: <20150702070828.GH2080@kib.kiev.ua>
References:  <CAFMmRNxLV0Uk9iT%2BU8rrPvn6aanSfEA6p577McM=_4xypaZr5w@mail.gmail.com> <CAFOYbckF7brPikTPaf%2BZhdm-R9d0WzygY9-eUxnrmi3p%2BBFBoQ@mail.gmail.com> <CAFMmRNzLL-K0kw_cj==kWpiocOcBLzxU2o6ONGaZRiv5tdSHxQ@mail.gmail.com> <20150701213241.GG2080@kib.kiev.ua> <CAFMmRNyeEp0gccRAspkJNT_tFWZvJWEczNitB8nCyOzSWKZBWA@mail.gmail.com> <20150702070828.GH2080@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 2, 2015 at 3:08 AM, Konstantin Belousov <kostikbel@gmail.com>
wrote:

> Having taskqueue_enqueue() which could silently (?) not enqueue the given
> task is huge and IMO risky change to the KPI.  If doing it, I think
> that there should be a new function to enqueue, which is allowed to
> fail, unlike taskqueue_enqueue().
>
> BTW, the man page for taskqueue(9) is wrong, taskqueue_enqueue(9)
> always succeed now and always returns 0 (ignoring the ushort overflow).
>

That's fair, but I feel that a new enqueue function would be rather
intrusive for existing drivers.  Maybe we should attach this from a
different angle.  How about a taskqueue_quiesce() function, which must be
called on a blocked taskqueue (by taskqueue_block() ).  taskqueue_quiesce()
would block until the taskqueue's thread has stopped running.  Then I can
do:

taskqueue_block()
taskqueue_quiesce()
taskqueue_cancel()
//...
taskqueue_free()



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNxGqdmrfLc3U9BW4BWzM_PxN0NO0i0NNrbC_Qsgf=2wUw>