Mojo EDK: Introduce MojoQueryHandleSignalsState API

Mojo EDK: Introduce MojoQueryHandleSignalsState API

The only reliable way to inquire about handle signals now
is to MojoWait (for e.g. 0 deadline). As a precursor to
removing the wait APIs in favor of watchers, we need to
retain the ability to efficiently query a handle's signals
state.

Rather than trying to retrofit the watcher APIs to support
this use case in similar fashion to the wait APIs, this adds
an API explicitly for the purpose of querying signals state.

Adds a corresponding method to the C++ mojo::Handle
and moves the EDK's internal HandleSignalsState helper class
to mojo/public/cpp/system, adding some convenient accessors.

Also introduces the API to the JS and Java libraries, and
replaces any 0-deadline waits in those languages with usage of
this new API.

Because waitMany is not used in these languages (except for
tests which test waitMany...) it has been removed. wait() is
unused in Java after this change, so it has also been removed.

Finally, this moves several tests away from calling MojoWait
directly, instead using a simplified Watcher-based wait
implementation in MojoTestBase.

BUG=700171
TBR=jam@chromium.org

Review-Url: https://codereview.chromium.org/2741033003
Cr-Original-Commit-Position: refs/heads/master@{#457315}
Committed: https://chromium.googlesource.com/chromium/src/+/853496a78ae997c2d8b80f3cd8fabf9423fb3361
Review-Url: https://codereview.chromium.org/2741033003
Cr-Commit-Position: refs/heads/master@{#457378}
Committed: https://chromium.googlesource.com/chromium/src/+/c7949549ac0c42252c8b3f2c08d4cb34b65dc869

[Ken Rockot(use gerrit already), 2017-03-09 22:27:05]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-09 22:27:53]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-09 22:38:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-09 22:38:55]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Ken Rockot(use gerrit already), 2017-03-09 22:41:36]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-09 22:42:24]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-10 02:13:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-10 02:13:23]

Dry run: This issue passed the CQ dry run.

[Ken Rockot(use gerrit already), 2017-03-12 21:47:08]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-12 21:47:31]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-12 22:00:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-12 22:00:02]

Dry run: Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[Ken Rockot(use gerrit already), 2017-03-12 22:21:12]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-12 22:21:26]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-12 23:09:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-12 23:09:26]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Ken Rockot(use gerrit already), 2017-03-13 16:16:33]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-13 16:16:54]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ken Rockot(use gerrit already), 2017-03-13 16:17:54]

Description was changed from

==========
Mojo EDK: Introduce MojoQueryHandleSignalsState API

The only reliable way to inquire about handle signals now
is to MojoWait (for e.g. 0 deadline). As a precursor to
removing the wait APIs in favor of watchers, we need to
retain the ability to efficiently query a handle's signals
state.

Rather than trying to retrofit the watcher APIs to support
this use case in similar fashion to the wait APIs, this adds
an API explicitly for the purpose of querying signals state.

Also adds a corresponding method to the C++ mojo::Handle
and moves the EDK internal HandleSignalsState helper class
to mojo/public/cpp/system, adding some convenient accessors.

BUG=700171
==========

to

==========
Mojo EDK: Introduce MojoQueryHandleSignalsState API

The only reliable way to inquire about handle signals now
is to MojoWait (for e.g. 0 deadline). As a precursor to
removing the wait APIs in favor of watchers, we need to
retain the ability to efficiently query a handle's signals
state.

Rather than trying to retrofit the watcher APIs to support
this use case in similar fashion to the wait APIs, this adds
an API explicitly for the purpose of querying signals state.

Adds a corresponding method to the C++ mojo::Handle
and moves the EDK's internal HandleSignalsState helper class
to mojo/public/cpp/system, adding some convenient accessors.

Also introduces the API to the JS and Java libraries, and
replaces any 0-deadline waits in those languages with usage of
this new API.

BUG=700171
==========

[Ken Rockot(use gerrit already), 2017-03-13 16:31:04]

Description was changed from

==========
Mojo EDK: Introduce MojoQueryHandleSignalsState API

The only reliable way to inquire about handle signals now
is to MojoWait (for e.g. 0 deadline). As a precursor to
removing the wait APIs in favor of watchers, we need to
retain the ability to efficiently query a handle's signals
state.

Rather than trying to retrofit the watcher APIs to support
this use case in similar fashion to the wait APIs, this adds
an API explicitly for the purpose of querying signals state.

Adds a corresponding method to the C++ mojo::Handle
and moves the EDK's internal HandleSignalsState helper class
to mojo/public/cpp/system, adding some convenient accessors.

Also introduces the API to the JS and Java libraries, and
replaces any 0-deadline waits in those languages with usage of
this new API.

BUG=700171
==========

to

==========
Mojo EDK: Introduce MojoQueryHandleSignalsState API

The only reliable way to inquire about handle signals now
is to MojoWait (for e.g. 0 deadline). As a precursor to
removing the wait APIs in favor of watchers, we need to
retain the ability to efficiently query a handle's signals
state.

Rather than trying to retrofit the watcher APIs to support
this use case in similar fashion to the wait APIs, this adds
an API explicitly for the purpose of querying signals state.

Adds a corresponding method to the C++ mojo::Handle
and moves the EDK's internal HandleSignalsState helper class
to mojo/public/cpp/system, adding some convenient accessors.

Also introduces the API to the JS and Java libraries, and
replaces any 0-deadline waits in those languages with usage of
this new API.

Because waitMany is not used in these languages (except for
tests which test waitMany...) it has been removed. wait() is
unused in Java after this change, so it has also been removed.

BUG=700171
==========

[Ken Rockot(use gerrit already), 2017-03-13 16:38:03]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-13 16:38:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-13 18:15:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-13 18:15:47]

Dry run: This issue passed the CQ dry run.

[Ken Rockot(use gerrit already), 2017-03-13 22:14:55]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-13 22:16:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ken Rockot(use gerrit already), 2017-03-13 22:17:23]

Description was changed from

==========
Mojo EDK: Introduce MojoQueryHandleSignalsState API

The only reliable way to inquire about handle signals now
is to MojoWait (for e.g. 0 deadline). As a precursor to
removing the wait APIs in favor of watchers, we need to
retain the ability to efficiently query a handle's signals
state.

Rather than trying to retrofit the watcher APIs to support
this use case in similar fashion to the wait APIs, this adds
an API explicitly for the purpose of querying signals state.

Adds a corresponding method to the C++ mojo::Handle
and moves the EDK's internal HandleSignalsState helper class
to mojo/public/cpp/system, adding some convenient accessors.

Also introduces the API to the JS and Java libraries, and
replaces any 0-deadline waits in those languages with usage of
this new API.

Because waitMany is not used in these languages (except for
tests which test waitMany...) it has been removed. wait() is
unused in Java after this change, so it has also been removed.

BUG=700171
==========

to

==========
Mojo EDK: Introduce MojoQueryHandleSignalsState API

The only reliable way to inquire about handle signals now
is to MojoWait (for e.g. 0 deadline). As a precursor to
removing the wait APIs in favor of watchers, we need to
retain the ability to efficiently query a handle's signals
state.

Rather than trying to retrofit the watcher APIs to support
this use case in similar fashion to the wait APIs, this adds
an API explicitly for the purpose of querying signals state.

Adds a corresponding method to the C++ mojo::Handle
and moves the EDK's internal HandleSignalsState helper class
to mojo/public/cpp/system, adding some convenient accessors.

Also introduces the API to the JS and Java libraries, and
replaces any 0-deadline waits in those languages with usage of
this new API.

Because waitMany is not used in these languages (except for
tests which test waitMany...) it has been removed. wait() is
unused in Java after this change, so it has also been removed.

Finally, this moves several tests away from calling MojoWait
directly, instead using a simplified Watcher-based wait
implementation in MojoTestBase.

BUG=700171
==========

[Ken Rockot(use gerrit already), 2017-03-13 22:18:18]

rockot@chromium.org changed reviewers:
+ yzshen@chromium.org

[Ken Rockot(use gerrit already), 2017-03-13 22:18:19]

Another one for consideration at your leisure :)

Most of the churn here is just renaming calls to MojoWait in tests.

[commit-bot: I haz the power, 2017-03-13 23:58:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-13 23:58:07]

Dry run: This issue passed the CQ dry run.

[yzshen1, 2017-03-14 18:20:45]

LGTM with a few nits.

https://codereview.chromium.org/2741033003/diff/120001/content/child/web_data...
File content/child/web_data_consumer_handle_impl.cc (right):

https://codereview.chromium.org/2741033003/diff/120001/content/child/web_data...
content/child/web_data_consumer_handle_impl.cc:69: else if
(state.never_readable())
nit: I think the style guide says we don't need "else" in this case.

https://codereview.chromium.org/2741033003/diff/120001/mojo/edk/test/mojo_tes...
File mojo/edk/test/mojo_test_base.cc (right):

https://codereview.chromium.org/2741033003/diff/120001/mojo/edk/test/mojo_tes...
mojo/edk/test/mojo_test_base.cc:46: new scoped_refptr<Context>(context_))));
I feel that it is a little easier to read if we use the raw |content_.get()|
pointer (plus one ref) as the context and manually release later.

WDYT?

https://codereview.chromium.org/2741033003/diff/120001/mojo/public/cpp/system...
File mojo/public/cpp/system/handle.h (right):

https://codereview.chromium.org/2741033003/diff/120001/mojo/public/cpp/system...
mojo/public/cpp/system/handle.h:179: return
static_cast<HandleSignalsState>(signals_state);
nit: no need to static_cast

https://codereview.chromium.org/2741033003/diff/120001/mojo/public/cpp/system...
File mojo/public/cpp/system/handle_signals_state.h (right):

https://codereview.chromium.org/2741033003/diff/120001/mojo/public/cpp/system...
mojo/public/cpp/system/handle_signals_state.h:60: bool never_peer_closed() const
{
nit: does it make sense to add a comment what exactly never_peer_closed() means?

[Ken Rockot(use gerrit already), 2017-03-14 19:14:34]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-14 19:15:09]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ken Rockot(use gerrit already), 2017-03-14 19:15:46]

Description was changed from

==========
Mojo EDK: Introduce MojoQueryHandleSignalsState API

The only reliable way to inquire about handle signals now
is to MojoWait (for e.g. 0 deadline). As a precursor to
removing the wait APIs in favor of watchers, we need to
retain the ability to efficiently query a handle's signals
state.

Rather than trying to retrofit the watcher APIs to support
this use case in similar fashion to the wait APIs, this adds
an API explicitly for the purpose of querying signals state.

Adds a corresponding method to the C++ mojo::Handle
and moves the EDK's internal HandleSignalsState helper class
to mojo/public/cpp/system, adding some convenient accessors.

Also introduces the API to the JS and Java libraries, and
replaces any 0-deadline waits in those languages with usage of
this new API.

Because waitMany is not used in these languages (except for
tests which test waitMany...) it has been removed. wait() is
unused in Java after this change, so it has also been removed.

Finally, this moves several tests away from calling MojoWait
directly, instead using a simplified Watcher-based wait
implementation in MojoTestBase.

BUG=700171
==========

to

==========
Mojo EDK: Introduce MojoQueryHandleSignalsState API

The only reliable way to inquire about handle signals now
is to MojoWait (for e.g. 0 deadline). As a precursor to
removing the wait APIs in favor of watchers, we need to
retain the ability to efficiently query a handle's signals
state.

Rather than trying to retrofit the watcher APIs to support
this use case in similar fashion to the wait APIs, this adds
an API explicitly for the purpose of querying signals state.

Adds a corresponding method to the C++ mojo::Handle
and moves the EDK's internal HandleSignalsState helper class
to mojo/public/cpp/system, adding some convenient accessors.

Also introduces the API to the JS and Java libraries, and
replaces any 0-deadline waits in those languages with usage of
this new API.

Because waitMany is not used in these languages (except for
tests which test waitMany...) it has been removed. wait() is
unused in Java after this change, so it has also been removed.

Finally, this moves several tests away from calling MojoWait
directly, instead using a simplified Watcher-based wait
implementation in MojoTestBase.

BUG=700171
TBR=jam@chromium.org
==========

[Ken Rockot(use gerrit already), 2017-03-14 19:16:20]

Thanks!

TBRing jam@ for trivial content change

https://codereview.chromium.org/2741033003/diff/120001/content/child/web_data...
File content/child/web_data_consumer_handle_impl.cc (right):

https://codereview.chromium.org/2741033003/diff/120001/content/child/web_data...
content/child/web_data_consumer_handle_impl.cc:69: else if
(state.never_readable())
On 2017/03/14 at 18:20:44, yzshen1 wrote:
> nit: I think the style guide says we don't need "else" in this case.

Ah right, done

https://codereview.chromium.org/2741033003/diff/120001/mojo/edk/test/mojo_tes...
File mojo/edk/test/mojo_test_base.cc (right):

https://codereview.chromium.org/2741033003/diff/120001/mojo/edk/test/mojo_tes...
mojo/edk/test/mojo_test_base.cc:46: new scoped_refptr<Context>(context_))));
On 2017/03/14 at 18:20:44, yzshen1 wrote:
> I feel that it is a little easier to read if we use the raw |content_.get()|
pointer (plus one ref) as the context and manually release later.
> 
> WDYT?

Done

https://codereview.chromium.org/2741033003/diff/120001/mojo/public/cpp/system...
File mojo/public/cpp/system/handle.h (right):

https://codereview.chromium.org/2741033003/diff/120001/mojo/public/cpp/system...
mojo/public/cpp/system/handle.h:179: return
static_cast<HandleSignalsState>(signals_state);
On 2017/03/14 at 18:20:45, yzshen1 wrote:
> nit: no need to static_cast

Oops, done

https://codereview.chromium.org/2741033003/diff/120001/mojo/public/cpp/system...
File mojo/public/cpp/system/handle_signals_state.h (right):

https://codereview.chromium.org/2741033003/diff/120001/mojo/public/cpp/system...
mojo/public/cpp/system/handle_signals_state.h:60: bool never_peer_closed() const
{
On 2017/03/14 at 18:20:45, yzshen1 wrote:
> nit: does it make sense to add a comment what exactly never_peer_closed()
means?

Done

[commit-bot: I haz the power, 2017-03-14 21:44:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-14 21:44:38]

Dry run: This issue passed the CQ dry run.

[Ken Rockot(use gerrit already), 2017-03-15 22:53:08]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-15 22:53:37]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-16 00:58:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-16 00:58:51]

Dry run: This issue passed the CQ dry run.

[Ken Rockot(use gerrit already), 2017-03-16 02:11:01]

The CQ bit was checked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2017-03-16 02:11:01]

The patchset sent to the CQ was uploaded after l-g-t-m from yzshen@chromium.org
Link to the patchset: https://codereview.chromium.org/2741033003/#ps160001
(title: "rebase")

[commit-bot: I haz the power, 2017-03-16 02:11:27]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-16 02:18:49]

CQ is committing da patch.

Bot data: {"patchset_id": 160001, "attempt_start_ts": 1489630261143020,
"parent_rev": "2879e8ebd796a5a459f0297624b284e32ec6ae9a", "commit_rev":
"853496a78ae997c2d8b80f3cd8fabf9423fb3361"}

[commit-bot: I haz the power, 2017-03-16 02:19:28]

Description was changed from

==========
Mojo EDK: Introduce MojoQueryHandleSignalsState API

The only reliable way to inquire about handle signals now
is to MojoWait (for e.g. 0 deadline). As a precursor to
removing the wait APIs in favor of watchers, we need to
retain the ability to efficiently query a handle's signals
state.

Rather than trying to retrofit the watcher APIs to support
this use case in similar fashion to the wait APIs, this adds
an API explicitly for the purpose of querying signals state.

Adds a corresponding method to the C++ mojo::Handle
and moves the EDK's internal HandleSignalsState helper class
to mojo/public/cpp/system, adding some convenient accessors.

Also introduces the API to the JS and Java libraries, and
replaces any 0-deadline waits in those languages with usage of
this new API.

Because waitMany is not used in these languages (except for
tests which test waitMany...) it has been removed. wait() is
unused in Java after this change, so it has also been removed.

Finally, this moves several tests away from calling MojoWait
directly, instead using a simplified Watcher-based wait
implementation in MojoTestBase.

BUG=700171
TBR=jam@chromium.org
==========

to

==========
Mojo EDK: Introduce MojoQueryHandleSignalsState API

The only reliable way to inquire about handle signals now
is to MojoWait (for e.g. 0 deadline). As a precursor to
removing the wait APIs in favor of watchers, we need to
retain the ability to efficiently query a handle's signals
state.

Rather than trying to retrofit the watcher APIs to support
this use case in similar fashion to the wait APIs, this adds
an API explicitly for the purpose of querying signals state.

Adds a corresponding method to the C++ mojo::Handle
and moves the EDK's internal HandleSignalsState helper class
to mojo/public/cpp/system, adding some convenient accessors.

Also introduces the API to the JS and Java libraries, and
replaces any 0-deadline waits in those languages with usage of
this new API.

Because waitMany is not used in these languages (except for
tests which test waitMany...) it has been removed. wait() is
unused in Java after this change, so it has also been removed.

Finally, this moves several tests away from calling MojoWait
directly, instead using a simplified Watcher-based wait
implementation in MojoTestBase.

BUG=700171
TBR=jam@chromium.org

Review-Url: https://codereview.chromium.org/2741033003
Cr-Commit-Position: refs/heads/master@{#457315}
Committed:
https://chromium.googlesource.com/chromium/src/+/853496a78ae997c2d8b80f3cd8fa...
==========

[commit-bot: I haz the power, 2017-03-16 02:19:30]

Committed patchset #9 (id:160001) as
https://chromium.googlesource.com/chromium/src/+/853496a78ae997c2d8b80f3cd8fa...

[tzik, 2017-03-16 03:57:26]

A revert of this CL (patchset #9 id:160001) has been created in
https://codereview.chromium.org/2750273002/ by tzik@chromium.org.

The reason for reverting is: This CL seems to break mojo_system_unittests on
multiple bots:

https://build.chromium.org/p/chromium.linux/builders/Linux%20Tests/builds/53232
https://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%281%29/bui...
https://build.chromium.org/p/chromium.mac/builders/Mac10.11%20Tests/builds/9606

Here are samples of the failing tests. Most of them are failed by time out:
MessagePipeTest.DiscardMode
WatcherTest.WatchDataPipeConsumerReadable
WatcherTest.WatchMessagePipeReadable
MessagePipeTest.Basic
DataPipeTest.PeerClosedProducerWaiting
.

[Ken Rockot(use gerrit already), 2017-03-16 04:07:19]

Doh. Thanks for reverting. It is immediately obvious to me that I
accidentally left in a DCHECK with side effects. I'll upload a new PS and
reland.

On Wed, Mar 15, 2017 at 8:57 PM, <tzik@chromium.org> wrote:

> A revert of this CL (patchset #9 id:160001) has been created in
> https://codereview.chromium.org/2750273002/ by tzik@chromium.org.
>
> The reason for reverting is: This CL seems to break mojo_system_unittests
> on
> multiple bots:
>
> https://build.chromium.org/p/chromium.linux/builders/Linux%
> 20Tests/builds/53232
> https://build.chromium.org/p/chromium.win/builders/Win7%
> 20Tests%20%281%29/builds/64801
> https://build.chromium.org/p/chromium.mac/builders/Mac10.
> 11%20Tests/builds/9606
>
> Here are samples of the failing tests. Most of them are failed by time out:
> MessagePipeTest.DiscardMode
> WatcherTest.WatchDataPipeConsumerReadable
> WatcherTest.WatchMessagePipeReadable
> MessagePipeTest.Basic
> DataPipeTest.PeerClosedProducerWaiting
> .
>
> https://codereview.chromium.org/2741033003/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ken Rockot(use gerrit already), 2017-03-16 04:10:18]

The CQ bit was checked by rockot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-16 04:10:31]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Ken Rockot(use gerrit already), 2017-03-16 04:17:49]

The CQ bit was unchecked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2017-03-16 04:17:53]

The CQ bit was checked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2017-03-16 04:17:53]

The patchset sent to the CQ was uploaded after l-g-t-m from yzshen@chromium.org
Link to the patchset: https://codereview.chromium.org/2741033003/#ps180001
(title: "fix stupid bad DCHECK")

[commit-bot: I haz the power, 2017-03-16 04:18:14]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-16 04:54:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-16 04:54:38]

Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[Ken Rockot(use gerrit already), 2017-03-16 04:57:37]

The CQ bit was checked by rockot@chromium.org

[commit-bot: I haz the power, 2017-03-16 04:57:50]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-16 05:31:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-16 05:31:41]

Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Ken Rockot(use gerrit already), 2017-03-16 06:38:28]

The CQ bit was checked by rockot@chromium.org

[commit-bot: I haz the power, 2017-03-16 06:38:40]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-16 09:03:51]

CQ is committing da patch.

Bot data: {"patchset_id": 180001, "attempt_start_ts": 1489646308026200,
"parent_rev": "200763220d087ef3ccf735855398ec193db29658", "commit_rev":
"c7949549ac0c42252c8b3f2c08d4cb34b65dc869"}

[commit-bot: I haz the power, 2017-03-16 09:04:57]

Description was changed from

==========
Mojo EDK: Introduce MojoQueryHandleSignalsState API

The only reliable way to inquire about handle signals now
is to MojoWait (for e.g. 0 deadline). As a precursor to
removing the wait APIs in favor of watchers, we need to
retain the ability to efficiently query a handle's signals
state.

Rather than trying to retrofit the watcher APIs to support
this use case in similar fashion to the wait APIs, this adds
an API explicitly for the purpose of querying signals state.

Adds a corresponding method to the C++ mojo::Handle
and moves the EDK's internal HandleSignalsState helper class
to mojo/public/cpp/system, adding some convenient accessors.

Also introduces the API to the JS and Java libraries, and
replaces any 0-deadline waits in those languages with usage of
this new API.

Because waitMany is not used in these languages (except for
tests which test waitMany...) it has been removed. wait() is
unused in Java after this change, so it has also been removed.

Finally, this moves several tests away from calling MojoWait
directly, instead using a simplified Watcher-based wait
implementation in MojoTestBase.

BUG=700171
TBR=jam@chromium.org

Review-Url: https://codereview.chromium.org/2741033003
Cr-Commit-Position: refs/heads/master@{#457315}
Committed:
https://chromium.googlesource.com/chromium/src/+/853496a78ae997c2d8b80f3cd8fa...
==========

to

==========
Mojo EDK: Introduce MojoQueryHandleSignalsState API

The only reliable way to inquire about handle signals now
is to MojoWait (for e.g. 0 deadline). As a precursor to
removing the wait APIs in favor of watchers, we need to
retain the ability to efficiently query a handle's signals
state.

Rather than trying to retrofit the watcher APIs to support
this use case in similar fashion to the wait APIs, this adds
an API explicitly for the purpose of querying signals state.

Adds a corresponding method to the C++ mojo::Handle
and moves the EDK's internal HandleSignalsState helper class
to mojo/public/cpp/system, adding some convenient accessors.

Also introduces the API to the JS and Java libraries, and
replaces any 0-deadline waits in those languages with usage of
this new API.

Because waitMany is not used in these languages (except for
tests which test waitMany...) it has been removed. wait() is
unused in Java after this change, so it has also been removed.

Finally, this moves several tests away from calling MojoWait
directly, instead using a simplified Watcher-based wait
implementation in MojoTestBase.

BUG=700171
TBR=jam@chromium.org

Review-Url: https://codereview.chromium.org/2741033003
Cr-Original-Commit-Position: refs/heads/master@{#457315}
Committed:
https://chromium.googlesource.com/chromium/src/+/853496a78ae997c2d8b80f3cd8fa...
Review-Url: https://codereview.chromium.org/2741033003
Cr-Commit-Position: refs/heads/master@{#457378}
Committed:
https://chromium.googlesource.com/chromium/src/+/c7949549ac0c42252c8b3f2c08d4...
==========

[commit-bot: I haz the power, 2017-03-16 09:04:59]

Committed patchset #10 (id:180001) as
https://chromium.googlesource.com/chromium/src/+/c7949549ac0c42252c8b3f2c08d4...