Rationalize AddAwakable...() and RemoveAwakable...() methods.

Rationalize AddAwakable...() and RemoveAwakable...() methods.

Despite the apparent size of this change, it's just one big make-work
project. But it'll help preserve (what little is left of) my sanity.

* Rearrange the order of parameters, so that the context always
  immediately follows the awakable pointer argument.
* Give Dispatcher::AddAwakable() a |force| parameter, like everywhere
  else, and get rid of its AddAwakableUnconditional().
* Give all the RemoveAwakable() (and similar variants) methods in
  various places a |match_context| boolean parameter and a |context|
  parameter (used only if |match_context| is true), and get rid of
  RemoveAwakableWithContext() (and similar variants).
* Change the behaviour of AddAwakable() when |force| is true, to also
  add when something is (currently) never-satisfiable. (Data pipe
  consumer/producers can sometimes go from "never"-satisfiable back to
  satisfiable due to a change of options.)

R=vardhan@google.com
BUG=#350

Committed: https://chromium.googlesource.com/external/mojo/+/8945984fcfe6f45ee825417a47e0d2d0451aee1d

[viettrungluu, 2016-06-21 18:23:37]

Description was changed from

==========
Rationalize AddAwakable...() and RemoveAwakable...() methods.

Despite the apparent size of this change, it's just one big make-work
project. But it'll help preserve (what little is left of) my sanity.

* Rearrange the order of parameters, so that the context always
  immediately follows the awakable pointer argument.
* Give Dispatcher::AddAwakable() a |force| parameter, like everywhere
  else, and get rid of its AddAwakableUnconditional().
* Give all the RemoveAwakable() (and similar variants) methods in
  various places a |match_context| boolean parameter and a |context|
  parameter (used only if |match_context| is true), and get rid of
  RemoveAwakableWithContext() (and similar variants).

R=vardhan@google.com
BUG=#350
==========

to

==========
Rationalize AddAwakable...() and RemoveAwakable...() methods.

Despite the apparent size of this change, it's just one big make-work
project. But it'll help preserve (what little is left of) my sanity.

* Rearrange the order of parameters, so that the context always
  immediately follows the awakable pointer argument.
* Give Dispatcher::AddAwakable() a |force| parameter, like everywhere
  else, and get rid of its AddAwakableUnconditional().
* Give all the RemoveAwakable() (and similar variants) methods in
  various places a |match_context| boolean parameter and a |context|
  parameter (used only if |match_context| is true), and get rid of
  RemoveAwakableWithContext() (and similar variants).
* Changed the behaviour of AddAwakable() when |force| is true, to also
  add when something is (currently) never-satisfiable. (Data pipe
  consumer/producers can sometimes go from "never"-satisfiable back to
  satisfiable due to a change of options.)

R=vardhan@google.com
BUG=#350
==========

[viettrungluu, 2016-06-21 18:23:48]

Description was changed from

==========
Rationalize AddAwakable...() and RemoveAwakable...() methods.

Despite the apparent size of this change, it's just one big make-work
project. But it'll help preserve (what little is left of) my sanity.

* Rearrange the order of parameters, so that the context always
  immediately follows the awakable pointer argument.
* Give Dispatcher::AddAwakable() a |force| parameter, like everywhere
  else, and get rid of its AddAwakableUnconditional().
* Give all the RemoveAwakable() (and similar variants) methods in
  various places a |match_context| boolean parameter and a |context|
  parameter (used only if |match_context| is true), and get rid of
  RemoveAwakableWithContext() (and similar variants).
* Changed the behaviour of AddAwakable() when |force| is true, to also
  add when something is (currently) never-satisfiable. (Data pipe
  consumer/producers can sometimes go from "never"-satisfiable back to
  satisfiable due to a change of options.)

R=vardhan@google.com
BUG=#350
==========

to

==========
Rationalize AddAwakable...() and RemoveAwakable...() methods.

Despite the apparent size of this change, it's just one big make-work
project. But it'll help preserve (what little is left of) my sanity.

* Rearrange the order of parameters, so that the context always
  immediately follows the awakable pointer argument.
* Give Dispatcher::AddAwakable() a |force| parameter, like everywhere
  else, and get rid of its AddAwakableUnconditional().
* Give all the RemoveAwakable() (and similar variants) methods in
  various places a |match_context| boolean parameter and a |context|
  parameter (used only if |match_context| is true), and get rid of
  RemoveAwakableWithContext() (and similar variants).
* Change the behaviour of AddAwakable() when |force| is true, to also
  add when something is (currently) never-satisfiable. (Data pipe
  consumer/producers can sometimes go from "never"-satisfiable back to
  satisfiable due to a change of options.)

R=vardhan@google.com
BUG=#350
==========

[viettrungluu, 2016-06-22 15:21:24]

ping

[vardhan, 2016-06-22 16:07:20]

lgtm

[viettrungluu, 2016-06-22 16:16:47]

Description was changed from

==========
Rationalize AddAwakable...() and RemoveAwakable...() methods.

Despite the apparent size of this change, it's just one big make-work
project. But it'll help preserve (what little is left of) my sanity.

* Rearrange the order of parameters, so that the context always
  immediately follows the awakable pointer argument.
* Give Dispatcher::AddAwakable() a |force| parameter, like everywhere
  else, and get rid of its AddAwakableUnconditional().
* Give all the RemoveAwakable() (and similar variants) methods in
  various places a |match_context| boolean parameter and a |context|
  parameter (used only if |match_context| is true), and get rid of
  RemoveAwakableWithContext() (and similar variants).
* Change the behaviour of AddAwakable() when |force| is true, to also
  add when something is (currently) never-satisfiable. (Data pipe
  consumer/producers can sometimes go from "never"-satisfiable back to
  satisfiable due to a change of options.)

R=vardhan@google.com
BUG=#350
==========

to

==========
Rationalize AddAwakable...() and RemoveAwakable...() methods.

Despite the apparent size of this change, it's just one big make-work
project. But it'll help preserve (what little is left of) my sanity.

* Rearrange the order of parameters, so that the context always
  immediately follows the awakable pointer argument.
* Give Dispatcher::AddAwakable() a |force| parameter, like everywhere
  else, and get rid of its AddAwakableUnconditional().
* Give all the RemoveAwakable() (and similar variants) methods in
  various places a |match_context| boolean parameter and a |context|
  parameter (used only if |match_context| is true), and get rid of
  RemoveAwakableWithContext() (and similar variants).
* Change the behaviour of AddAwakable() when |force| is true, to also
  add when something is (currently) never-satisfiable. (Data pipe
  consumer/producers can sometimes go from "never"-satisfiable back to
  satisfiable due to a change of options.)

R=vardhan@google.com
BUG=#350

Committed:
https://chromium.googlesource.com/external/mojo/+/8945984fcfe6f45ee825417a47e...
==========

[viettrungluu, 2016-06-22 16:16:55]

Committed patchset #2 (id:20001) manually as
8945984fcfe6f45ee825417a47e0d2d0451aee1d (presubmit successful).