Issue metadata
Sign in to add a comment
|
mojo WaitForIncomingMessage asserts on deadlines not 0 or not infinite
Reported by
artyo...@gmail.com,
Oct 5 2017
|
||||||||||||||||||||
Issue description
Steps to reproduce the problem:
Specify mojo deadline non 0 or non infinite.
What is the expected behavior?
If you try to specify the deadline for mojo::WaitForIncomingMessage (see connector.cc/.h) then it will throw an assert. This is the code which does it:
// TODO(rockot): Use a timed Wait here. Nobody uses anything but 0 or
// INDEFINITE deadlines at present, so we only support those.
DCHECK(deadline == 0 || deadline == MOJO_DEADLINE_INDEFINITE);
What went wrong?
Assert. It definitely worked in M57, for some reasons in M61 (maybe earlier) this functionality was removed (w/o actually removing the parameter for WaitForIncomingMessage!).
Did this work before? Yes M57
Does this work in other browsers? Yes
Chrome version: 61.0.3163.100 Channel: dev
OS Version: 10.0
Flash Version:
I rely on this functionality to avoid deadlock in certain situations.
,
Oct 5 2017
@artyom17: Thanks for the report!! Could you please help us with the sample test file or .apk file to check the issue from our end? Thanks!!
,
Oct 5 2017
You can easily repro it by modifying any call to WaitForIncomingMethodCall by providing non-zero-non-infinite deadline, like this (this one lives in VRDisplay.cpp): submit_frame_client_binding_.WaitForIncomingMethodCall(MojoDeadline(100000))
,
Oct 5 2017
Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 9 2017
Thanks for the feedback! Hi, Ken: What do you think about this? If it takes some work to support, I would suggest we remove the deadline parameter to avoid confusion, now that no one in the chromium reop is using it.
,
Oct 9 2017
I agree, we should remove it.
,
Apr 5 2018
Friendly ping. Is there any update on this issue.
,
Apr 5 2018
Removing what I assume are labels which inspired comment #7. I don't think this needs any triage, as it seems like a minor developer quality of life issue.
,
Oct 17
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by artyo...@gmail.com
, Oct 5 2017