PPAPI: Make CompletionCallbacks work right on background threads.

PPAPI: Make CompletionCallbacks work right on background threads.

Now, TrackedCallback::Run will:
-Run the callback immediately if it is on the right thread.
-PostRun to the correct thread if it is not.

This was preceded by https://chromiumcodereview.appspot.com/10909244/, which removed ClearAndRun and does some other little cleanups to TrackedCallback to make it usable on background threads.


BUG=92909
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=166719

[dmichael (off chromium), 2012-11-06 22:49:39]

I think this is ready for review now.

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter.cc
File ppapi/thunk/enter.cc (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter....
ppapi/thunk/enter.cc:111: CHECK(IsMainThread());
^^^ I'm mildly afraid this could break internal plugins that are still
in-process (Chromoting... not sure what else). But if this gets hit, they're
clearly doing something wrong. And it makes my logic simpler.

[brettw, 2012-11-06 23:16:28]

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/proxy/ppb_me...
File ppapi/proxy/ppb_message_loop_proxy.cc (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/proxy/ppb_me...
ppapi/proxy/ppb_message_loop_proxy.cc:154: return 0;
I'd use NULL instead of 0.

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/proxy/ppb_me...
ppapi/proxy/ppb_message_loop_proxy.cc:215: return
MessageLoopResource::GetCurrent()->GetReference();
I don't think we want this to crash if there's no current one. Probably need to
check null before calling GetReference.

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/shared_impl/...
File ppapi/shared_impl/ppapi_globals.h (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/shared_impl/...
ppapi/shared_impl/ppapi_globals.h:114: // alwas return NULL on the host side,
where PPB_MessageLoop is not supported.
"alwas" spelling

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/shared_impl/...
File ppapi/shared_impl/ppb_message_loop_shared.h (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/shared_impl/...
ppapi/shared_impl/ppb_message_loop_shared.h:28: : public Resource, public
thunk::PPB_MessageLoop_API {
2nd public on next line (either everything fits on one line, or are all on
separate ones).

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/shared_impl/...
File ppapi/shared_impl/tracked_callback.cc (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/shared_impl/...
ppapi/shared_impl/tracked_callback.cc:101: if (aborted() && (result !=
PP_ERROR_ABORTED))
I would have probably kept the previous code here (omitted the != check since
it's redundant).

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/shared_impl/...
ppapi/shared_impl/tracked_callback.cc:131: // Copy |callback_| and look at
|aborted()| now, since |MarkAsCompleted()|
You mention aborted() here but I don't see anything in the code corresponding to
this.

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/tests/test_u...
File ppapi/tests/test_utils.cc (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/tests/test_u...
ppapi/tests/test_utils.cc:236: if (!(callback->target_loop_ ==
pp::MessageLoop_Dev::GetCurrent())) {
Use != instead?

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter.cc
File ppapi/thunk/enter.cc (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter....
ppapi/thunk/enter.cc:111: CHECK(IsMainThread());
I'm happy with this.

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter....
ppapi/thunk/enter.cc:134: // PP_OK_COMPLETIONPENDING. So we crash to make the
problem more obvious.
This contradicts the documentation. I'm also wondering if it's best to crash.
From a plugin author's perspective, if something isn't working, I start looking
at error codes. If a function call is crashing, I'm perplexed and think it's a
bug in the system. So I think I prefer the documented behavior better than
crashing here.

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter....
ppapi/thunk/enter.cc:141: LOG(FATAL) << message;
Does this do the right thing in NaCl? I'm not positive fatal assertions kill the
plugin.

[dmichael (off chromium), 2012-11-06 23:39:26]

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/proxy/ppb_me...
File ppapi/proxy/ppb_message_loop_proxy.cc (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/proxy/ppb_me...
ppapi/proxy/ppb_message_loop_proxy.cc:154: return 0;
On 2012/11/06 23:16:28, brettw wrote:
> I'd use NULL instead of 0.

Done.

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/proxy/ppb_me...
ppapi/proxy/ppb_message_loop_proxy.cc:215: return
MessageLoopResource::GetCurrent()->GetReference();
On 2012/11/06 23:16:28, brettw wrote:
> I don't think we want this to crash if there's no current one. Probably need
to
> check null before calling GetReference.

Done.

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/shared_impl/...
File ppapi/shared_impl/ppapi_globals.h (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/shared_impl/...
ppapi/shared_impl/ppapi_globals.h:114: // alwas return NULL on the host side,
where PPB_MessageLoop is not supported.
On 2012/11/06 23:16:28, brettw wrote:
> "alwas" spelling
Darn, that put me over 80 chars ;-)

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/shared_impl/...
File ppapi/shared_impl/ppb_message_loop_shared.h (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/shared_impl/...
ppapi/shared_impl/ppb_message_loop_shared.h:28: : public Resource, public
thunk::PPB_MessageLoop_API {
On 2012/11/06 23:16:28, brettw wrote:
> 2nd public on next line (either everything fits on one line, or are all on
> separate ones).

Done.

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/tests/test_u...
File ppapi/tests/test_utils.cc (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/tests/test_u...
ppapi/tests/test_utils.cc:236: if (!(callback->target_loop_ ==
pp::MessageLoop_Dev::GetCurrent())) {
On 2012/11/06 23:16:28, brettw wrote:
> Use != instead?
I was being lazy, since pp::Resource didn't have operator!=.

Added it, done.

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter.cc
File ppapi/thunk/enter.cc (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter....
ppapi/thunk/enter.cc:134: // PP_OK_COMPLETIONPENDING. So we crash to make the
problem more obvious.
On 2012/11/06 23:16:28, brettw wrote:
> This contradicts the documentation. I'm also wondering if it's best to crash.
> From a plugin author's perspective, if something isn't working, I start
looking
> at error codes. If a function call is crashing, I'm perplexed and think it's a
> bug in the system. So I think I prefer the documented behavior better than
> crashing here.
This is *only* for required callbacks. They're not expecting anything but
PP_OK_COMPLETIONPENDING, and might not even be looking for it. This is the
resolution we came up with here:
https://groups.google.com/a/chromium.org/d/topic/pepper-dev/dSHfzSFPyuA/discu...
But I'm happy to revisit if you want.

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter....
ppapi/thunk/enter.cc:141: LOG(FATAL) << message;
On 2012/11/06 23:16:28, brettw wrote:
> Does this do the right thing in NaCl? I'm not positive fatal assertions kill
the
> plugin.
It looks like it to me in base/logging and base/debug/debugger_posix.cc (CHECK()
becomes LOG(FATAL) which calls BreakDebugger which calls abort() on NaCl).
Should kill the nexe.

I can slap together a local test to confirm it.

[brettw, 2012-11-07 00:02:21]

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter.cc
File ppapi/thunk/enter.cc (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter....
ppapi/thunk/enter.cc:134: // PP_OK_COMPLETIONPENDING. So we crash to make the
problem more obvious.
Okay, I don't care that much and since this was already discussed, we can keep
the crash. But we should update the message loop documentation which mentions
this case explicitly.

[dmichael (off chromium), 2012-11-07 18:44:34]

I improved PP_CompletionCallback documentation. +teravest so we can get a fresh
pair of eyes to look at it and make sure it's accessible enough.

I'm going to have to revisit pp::CompletionCallback once MessageLoop is out of
Dev. I'll also need to update CompletionCallbackFactory (at least documentation,
maybe more) but I'd like to do that in a separate CL.

PTAL

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/shared_impl/...
File ppapi/shared_impl/tracked_callback.cc (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/shared_impl/...
ppapi/shared_impl/tracked_callback.cc:101: if (aborted() && (result !=
PP_ERROR_ABORTED))
On 2012/11/06 23:16:28, brettw wrote:
> I would have probably kept the previous code here (omitted the != check since
> it's redundant).
Done. I was trying to make it look less weird with the stuff on 94 and 95, but I
guess it didn't help. I think the code is right, it just looks wrongish at first
glance.

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/shared_impl/...
ppapi/shared_impl/tracked_callback.cc:131: // Copy |callback_| and look at
|aborted()| now, since |MarkAsCompleted()|
On 2012/11/06 23:16:28, brettw wrote:
> You mention aborted() here but I don't see anything in the code corresponding
to
> this.
Copy paste error; fixed.

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter.cc
File ppapi/thunk/enter.cc (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter....
ppapi/thunk/enter.cc:134: // PP_OK_COMPLETIONPENDING. So we crash to make the
problem more obvious.
On 2012/11/07 00:02:21, brettw wrote:
> Okay, I don't care that much and since this was already discussed, we can keep
> the crash. But we should update the message loop documentation which mentions
> this case explicitly.
I didn't see anything wrong in the message loop documentation. It mentions
required callbacks, but it's in the context of PostWork, where the flags are
ignored. I think that documentation is still right.

The case I'm handling here is where a method taking a callback is invoked on a
background thread, and passed a required callback. The caller always expects
PP_OK_COMPLETIONPENDING in this case, and for us to run the callback later (even
in case of error). But we have no place to run it, and returning an error code
might not help (they might not even bother checking it). Hence why we crash.

I did find that PP_CompletionCallback's documentation was wrong in other ways,
and made no mention of this case. So I tried to clean that up.

[brettw, 2012-11-07 18:52:15]

lgtm

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter.cc
File ppapi/thunk/enter.cc (right):

https://chromiumcodereview.appspot.com/10910099/diff/32001/ppapi/thunk/enter....
ppapi/thunk/enter.cc:134: // PP_OK_COMPLETIONPENDING. So we crash to make the
problem more obvious.
You're right, I was looking at PostWork.

[teravest, 2012-11-07 21:11:40]

lgtm

[commit-bot: I haz the power, 2012-11-07 21:40:06]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10910099/37001

[commit-bot: I haz the power, 2012-11-07 22:08:40]

Sorry for I got bad news for ya.
Compile failed with a clobber build on win.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win&number...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2012-11-07 22:32:06]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10910099/37001

[commit-bot: I haz the power, 2012-11-07 22:46:07]

Sorry for I got bad news for ya.
Compile failed with a clobber build on win.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win&number...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2012-11-07 22:59:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10910099/37001

[commit-bot: I haz the power, 2012-11-07 23:12:59]

Sorry for I got bad news for ya.
Compile failed with a clobber build on win.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win&number...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2012-11-08 04:20:44]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10910099/47001

[commit-bot: I haz the power, 2012-11-08 07:32:39]

Retried try job too often for step(s) compile

[commit-bot: I haz the power, 2012-11-08 15:58:37]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10910099/21021

[commit-bot: I haz the power, 2012-11-08 18:55:18]

Change committed as 166719