Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1344332

Re: [PATCH v5 05/20] kthread: Add destroy_kthread_worker()

From Petr Mladek <pmladek@suse.com>
Newsgroups linux.kernel
Subject Re: [PATCH v5 05/20] kthread: Add destroy_kthread_worker()
Date 2016-02-26 16:20 +0100
Message-ID <r6sls-5aU-21@gated-at.bofh.it> (permalink)
References <r507T-7eO-3@gated-at.bofh.it> <r507U-7eO-7@gated-at.bofh.it> <r63n5-3MM-27@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu 2016-02-25 13:36:41, Peter Zijlstra wrote:
> On Mon, Feb 22, 2016 at 03:56:55PM +0100, Petr Mladek wrote:
> > Also note that drain() correctly handles self-queuing works in compare
> > with flush().
> 
> Nothing seems to prevent adding more work after drain() observes
> list_empty().

You might want to drain() more times during the kthread worker life
time to make sure that the work is done.

The user is responsible for stopping any queuing when this function
is called. The user usually needs to handle this anyway because
producing a work that could not be queued would cause problems.

To be honest, I wanted to keep the main principles of the API
compatible with workqueues. It should reduce some potential confusion.
Also it will make it easier to convert between the two APIs.
IMHO, there are work loads when you are not sure if you will
need a dedicated kthread when designing a new functionality.

Best Regards,
Petr

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [PATCH v5 05/20] kthread: Add destroy_kthread_worker() Peter Zijlstra <peterz@infradead.org> - 2016-02-25 13:40 +0100
  Re: [PATCH v5 05/20] kthread: Add destroy_kthread_worker() Petr Mladek <pmladek@suse.com> - 2016-02-26 16:20 +0100

csiph-web