All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarek Poplawski <jarkao2@o2.pl>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Howells <dhowells@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] rename cancel_rearming_delayed_work() to cancel_delayed_work_sync()
Date: Mon, 2 Jul 2007 15:45:02 +0200	[thread overview]
Message-ID: <20070702134502.GF1639@ff.dom.local> (raw)
In-Reply-To: <20070702121447.GA261@tv-sign.ru>

On Mon, Jul 02, 2007 at 04:14:47PM +0400, Oleg Nesterov wrote:
> On 07/02, Jarek Poplawski wrote:
> >
> > On Sun, Jul 01, 2007 at 07:36:29PM +0400, Oleg Nesterov wrote:
> > > Imho, the current naming of cancel_xxx workqueue functions is very confusing.
> > > 
> > > 	cancel_delayed_work()
> > > 	cancel_rearming_delayed_work()
> > > 	cancel_rearming_delayed_workqueue()	// obsolete
> > > 
> > > 	cancel_work_sync()
> > > 
> > > This looks as if the first 2 functions differ in "type" of their argument which
> > > is not true any longer, nowadays the difference is the behaviour.
> > > 
> > > The semantics of cancel_rearming_delayed_work(dwork) was changed significantly,
> > > it doesn't require that dwork rearms itself, and cancels dwork synchronously.
> > > 
> > > Rename it to cancel_delayed_work_sync(). This matches cancel_delayed_work() and
> > > cancel_work_sync(). Re-create cancel_rearming_delayed_work() as a simple inline
> > > obsolete wrapper, like cancel_rearming_delayed_workqueue().
> > 
> > I like the idea of this change, but have some doubt: "_sync"
> > usually suggests the main difference from "" (or _nosync) is:
> > _sync waits for something, while _nosync doesn't wait and
> > instantly returns.
> 
> Yes, but we already have cancel_work_sync().

And it's OK because it actually can block. Some confusion
could appear (maybe to me only) if we would add cancel_work()
which would also ... block.

> 
> > Here it's a bit complicated: cancel_delayed_work() (so nosync),
> > actually can wait a little too (on del_timer_sync). And
> > cancel_rearming_delayed_work() is really more universal now,
> > but still the main difference is this should be used with works
> > that rearm (at least sometimes). If there is no rearming - no
> > reason for this function (of course not forbidden too)  - and
> > maybe it better helps to remember the difference?
> 
> There is a reason even if no rearming. We have a lot of
> 
> 	cancel_delayed_work();
> 	flush_workqueue();
> 
> This should be converted to use cancel_delayed_work_sync().
> 
> Note also that both cancel_work_sync() and cancel_rearming_delayed_work()
> can be used on any work (rearming or not) and both imply "flush".
> I think the "_rearming" part of the name is very confusing, and a "good"
> name should be consistent with cancel_work_sync() and cancel_delayed_work()
> which we already have.

I know, but I'm a little afraid of "overloading" the "_sync":
here it's kind of double sync (can block plus really finish
something). I wonder if this way is used elsewhere in linux.

But I see the more serious reason for it is: it's in your next
patches and we don't want to waste time. So, I'll try to check
this in the evening, and if nothing strange - I'll send acks
tomorrow (of course - not that I think they are needed...).

Thanks,
Jarek P.

  reply	other threads:[~2007-07-02 13:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-01 15:36 [PATCH 1/3] rename cancel_rearming_delayed_work() to cancel_delayed_work_sync() Oleg Nesterov
2007-07-02 11:45 ` Jarek Poplawski
2007-07-02 12:14   ` Oleg Nesterov
2007-07-02 13:45     ` Jarek Poplawski [this message]
2007-07-03  5:28 ` Jarek Poplawski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070702134502.GF1639@ff.dom.local \
    --to=jarkao2@o2.pl \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@tv-sign.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.