PPAPI: Add dev synchronous JS->Plugin messaging API

PPAPI: Add dev synchronous JS->Plugin messaging API

BUG=367896
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=274349

[teravest, 2014-05-01 19:20:38]

https://codereview.chromium.org/252023009/diff/40001/ppapi/api/ppp_message_ha...
File ppapi/api/ppp_message_handler.idl (right):

https://codereview.chromium.org/252023009/diff/40001/ppapi/api/ppp_message_ha...
ppapi/api/ppp_message_handler.idl:1: /* Copyright (c) 2012 The Chromium Authors.
All rights reserved.
nit: 2014

https://codereview.chromium.org/252023009/diff/40001/ppapi/api/ppp_message_ha...
ppapi/api/ppp_message_handler.idl:35: * @param[in] user_data is the same as was
provided by a call to
nit: comments are out of order for params. Also true below.

https://codereview.chromium.org/252023009/diff/40001/ppapi/api/ppp_message_ha...
ppapi/api/ppp_message_handler.idl:42: * Invoked as a result of JavaScript
invoking postMessageAndAwaitResponse()
Where can I find more information on postMessageAndAwaitResponse()? I wasn't
able to find any information on it.

[dmichael (off chromium), 2014-05-01 19:55:00]

Thanks for looking!

https://codereview.chromium.org/252023009/diff/40001/ppapi/api/ppp_message_ha...
File ppapi/api/ppp_message_handler.idl (right):

https://codereview.chromium.org/252023009/diff/40001/ppapi/api/ppp_message_ha...
ppapi/api/ppp_message_handler.idl:1: /* Copyright (c) 2012 The Chromium Authors.
All rights reserved.
On 2014/05/01 19:20:38, teravest wrote:
> nit: 2014

Done.

https://codereview.chromium.org/252023009/diff/40001/ppapi/api/ppp_message_ha...
ppapi/api/ppp_message_handler.idl:35: * @param[in] user_data is the same as was
provided by a call to
On 2014/05/01 19:20:38, teravest wrote:
> nit: comments are out of order for params. Also true below.
> 

Done.

https://codereview.chromium.org/252023009/diff/40001/ppapi/api/ppp_message_ha...
ppapi/api/ppp_message_handler.idl:42: * Invoked as a result of JavaScript
invoking postMessageAndAwaitResponse()
On 2014/05/01 19:20:38, teravest wrote:
> Where can I find more information on postMessageAndAwaitResponse()? I wasn't
> able to find any information on it.
Sorry, this would be a new addition. Similar to how JavaScript can call
"postMessage" on the plugin element today:
https://code.google.com/p/chromium/codesearch#chromium/src/ppapi/examples/scr...
This API will expose a new function (in dev channel) called
postMessageAndAwaitResponse(), which has 1 parameter like postMessage, but
blocks until the plugin returns from HandleBlockingMessage...  and
postMessageAndAwaitResponse() will return a JavaScript value corresponding to
the PP_Var that HandleBlockingMessage returned.

I haven't done any of the plumbing, example, or test yet; so I don't have
anything to point you to yet.

The name is certainly up for debate; it's kind of long, but fairly descriptive.

[jvoung (off chromium), 2014-05-01 21:29:06]

https://codereview.chromium.org/252023009/diff/60001/ppapi/c/ppp_message_hand...
File ppapi/c/ppp_message_handler.h (right):

https://codereview.chromium.org/252023009/diff/60001/ppapi/c/ppp_message_hand...
ppapi/c/ppp_message_handler.h:35: * This interface struct should not be returned
by PPP_GetInterface; instead it
Just checking: Will there be any direct nexe <-> IRT boundary crossing between
these methods? E.g., The ppapi proxy calls the HandleMessage function supplied
by the nexe directly, passing a PP_Var by value?

The methods returned by PPP_GetInterface are shimmed to fix up calling
conventions, but it looks like these won't be?

https://codereview.chromium.org/252023009/diff/60001/ppapi/native_client/src/...
File ppapi/native_client/src/untrusted/pnacl_irt_shim/pnacl_shim.c (right):

https://codereview.chromium.org/252023009/diff/60001/ppapi/native_client/src/...
ppapi/native_client/src/untrusted/pnacl_irt_shim/pnacl_shim.c:6305: if
(mystrcmp(name, (*next)->iface_macro) == 0) return *next;
The mystrcmp currently doesn't handle NULL pointer arguments.

On the other hand, if the iface_macro is NULL the there might as well not be a
wrapper under s_ppp_wrappers, since it will never match in this search loop?

[darin (slow to review), 2014-05-02 08:02:15]

https://codereview.chromium.org/252023009/diff/60001/ppapi/api/ppp_message_ha...
File ppapi/api/ppp_message_handler.idl (right):

https://codereview.chromium.org/252023009/diff/60001/ppapi/api/ppp_message_ha...
ppapi/api/ppp_message_handler.idl:26: interface PPP_MessageHandler {
Perhaps an alternative approach is to expose a PPB_MessageQueue interface with a
method to Get (w/ CompletionCallback). This queue could be queried from any
thread.

Maybe the currently proposed API is better because it offers nicer guide rails
for developers?

[dmichael (off chromium), 2014-05-02 16:28:53]

https://codereview.chromium.org/252023009/diff/60001/ppapi/api/ppp_message_ha...
File ppapi/api/ppp_message_handler.idl (right):

https://codereview.chromium.org/252023009/diff/60001/ppapi/api/ppp_message_ha...
ppapi/api/ppp_message_handler.idl:26: interface PPP_MessageHandler {
On 2014/05/02 08:02:15, darin wrote:
> Perhaps an alternative approach is to expose a PPB_MessageQueue interface with
a
> method to Get (w/ CompletionCallback). This queue could be queried from any
> thread.
> 
> Maybe the currently proposed API is better because it offers nicer guide rails
> for developers?
Right, I started out down that road. It actually gives more flexibility, but I
didn't like how it made it easier to leave JavaScript blocked, whereas the
PPP_MessageHandler and return value approach makes it really hard to mess up,
since it's hard to forget to return from a function :-). Here's what I had
thrown together:
https://codereview.chromium.org/253813006/diff/1/ppapi/api/ppb_messaging.idl

Another disadvantage with that: I want to be able to detect when there is no
handler waiting in the plugin, so that JavaScript will get an immediate failure
if the plugin isn't waiting to handle the sync message. Using completion
callbacks, there's a time window when the plugin has responded using:
RespondToBlockingMessage()
but has not yet called
GetBlockingMessage()
to ask for the next message. During that time window, it's not obvious that the
plugin is going to handle more JavaScript messages. There are ways to work
around it, but...  overall, I didn't like the tradeoffs of going that way.

[dmichael (off chromium), 2014-05-02 18:03:41]

I talked over IM with jvoung about the PNaCl shim issues, but wanted to respond
here for completeness.

https://codereview.chromium.org/252023009/diff/60001/ppapi/c/ppp_message_hand...
File ppapi/c/ppp_message_handler.h (right):

https://codereview.chromium.org/252023009/diff/60001/ppapi/c/ppp_message_hand...
ppapi/c/ppp_message_handler.h:35: * This interface struct should not be returned
by PPP_GetInterface; instead it
On 2014/05/01 21:29:06, jvoung (wakacje 5th to 13th) wrote:
> Just checking: Will there be any direct nexe <-> IRT boundary crossing between
> these methods? E.g., The ppapi proxy calls the HandleMessage function supplied
> by the nexe directly, passing a PP_Var by value?
Yes, thanks for bringing it up...

> 
> The methods returned by PPP_GetInterface are shimmed to fix up calling
> conventions, but it looks like these won't be?
Correct, right now. I'm hoping there might be an explicit way for me to use the
PNaCl Shim wrapper that gets generated for PPP_MessageHandler directly. I was
hoping to keep the new HandleMessage and HandleBlockingMessage consistent with
the old HandleMessage, in that they pass a PP_Var by value.

I *can* also make it work just by passing the PP_Var by pointer. I think in the
near-term I might just do that.

[darin (slow to review), 2014-05-02 18:20:57]

On 2014/05/02 16:28:53, dmichael wrote:
>
https://codereview.chromium.org/252023009/diff/60001/ppapi/api/ppp_message_ha...
> File ppapi/api/ppp_message_handler.idl (right):
> 
>
https://codereview.chromium.org/252023009/diff/60001/ppapi/api/ppp_message_ha...
> ppapi/api/ppp_message_handler.idl:26: interface PPP_MessageHandler {
> On 2014/05/02 08:02:15, darin wrote:
> > Perhaps an alternative approach is to expose a PPB_MessageQueue interface
with
> a
> > method to Get (w/ CompletionCallback). This queue could be queried from any
> > thread.
> > 
> > Maybe the currently proposed API is better because it offers nicer guide
rails
> > for developers?
> Right, I started out down that road. It actually gives more flexibility, but I
> didn't like how it made it easier to leave JavaScript blocked, whereas the
> PPP_MessageHandler and return value approach makes it really hard to mess up,
> since it's hard to forget to return from a function :-). Here's what I had
> thrown together:
> https://codereview.chromium.org/253813006/diff/1/ppapi/api/ppb_messaging.idl
> 
> Another disadvantage with that: I want to be able to detect when there is no
> handler waiting in the plugin, so that JavaScript will get an immediate
failure
> if the plugin isn't waiting to handle the sync message. Using completion
> callbacks, there's a time window when the plugin has responded using:
> RespondToBlockingMessage()
> but has not yet called
> GetBlockingMessage()
> to ask for the next message. During that time window, it's not obvious that
the
> plugin is going to handle more JavaScript messages. There are ways to work
> around it, but...  overall, I didn't like the tradeoffs of going that way.

Makes sense. Thanks.

[jschuh, 2014-05-07 21:25:23]

tsepez@ - Could you take a closer look at this for me?

[Tom Sepez, 2014-05-07 22:27:10]

This doesn't seem to have any implementation of the JS side block yet, does it?

https://codereview.chromium.org/252023009/diff/60001/ppapi/proxy/ppapi_messag...
File ppapi/proxy/ppapi_messages.h (right):

https://codereview.chromium.org/252023009/diff/60001/ppapi/proxy/ppapi_messag...
ppapi/proxy/ppapi_messages.h:624:
IPC_SYNC_MESSAGE_ROUTED(PpapiMsg_PPPMessageHandler_HandleBlockingMessage,
Don't you mean IPC_SYNC_MESSAGE_ROUTED2_1?

[dmichael (off chromium), 2014-05-07 22:30:18]

Right, sorry, this doesn't need security review yet. I'm working on the backing
implementation, and there are lots of changes. And yes, I sketched out the
ppapi/proxy/ppapi_messages.h change and got it wrong :)

[dmichael (off chromium), 2014-05-30 20:30:45]

I think this is ready for re-review and landing. PTAL.

I have a working implementation CL at:
https://codereview.chromium.org/264303002/ that needs some rebasing work before
review.

The main changes vs the previous version:
1) Changed PP_Var arg of HandleMessage and HandleBlockingMessage to PP_Var* so
that PNaCl shims aren't necessary. Slightly a shame, but it's consistent with
how we pass other structs, at least.
2) Added comments saying it's not yet implemented. Will change to "dev channel
only" comments in the next CL.

https://codereview.chromium.org/252023009/diff/60001/ppapi/native_client/src/...
File ppapi/native_client/src/untrusted/pnacl_irt_shim/pnacl_shim.c (right):

https://codereview.chromium.org/252023009/diff/60001/ppapi/native_client/src/...
ppapi/native_client/src/untrusted/pnacl_irt_shim/pnacl_shim.c:6305: if
(mystrcmp(name, (*next)->iface_macro) == 0) return *next;
On 2014/05/01 21:29:06, jvoung wrote:
> The mystrcmp currently doesn't handle NULL pointer arguments.
> 
> On the other hand, if the iface_macro is NULL the there might as well not be a
> wrapper under s_ppp_wrappers, since it will never match in this search loop?
Done. See also https://codereview.chromium.org/305233002/

https://codereview.chromium.org/252023009/diff/60001/ppapi/proxy/ppapi_messag...
File ppapi/proxy/ppapi_messages.h (right):

https://codereview.chromium.org/252023009/diff/60001/ppapi/proxy/ppapi_messag...
ppapi/proxy/ppapi_messages.h:624:
IPC_SYNC_MESSAGE_ROUTED(PpapiMsg_PPPMessageHandler_HandleBlockingMessage,
On 2014/05/07 22:27:10, Tom Sepez wrote:
> Don't you mean IPC_SYNC_MESSAGE_ROUTED2_1?
Removed from this CL. The implementation CL will add the new message...
https://codereview.chromium.org/264303002/

[teravest, 2014-05-30 20:36:14]

lgtm

https://codereview.chromium.org/252023009/diff/100001/ppapi/api/ppb_messaging...
File ppapi/api/ppb_messaging.idl (right):

https://codereview.chromium.org/252023009/diff/100001/ppapi/api/ppb_messaging...
ppapi/api/ppb_messaging.idl:89: *
nit: you shouldn't need the extra newline here.

https://codereview.chromium.org/252023009/diff/100001/ppapi/api/ppb_messaging...
ppapi/api/ppb_messaging.idl:117: * @param[in] message_loop represents the
message loop on which
nit: s/represents/Represents/ for consistent style.

https://codereview.chromium.org/252023009/diff/100001/ppapi/api/ppb_messaging...
ppapi/api/ppb_messaging.idl:127: *
nit: same as above for newline. Unless this is required for some interaction
with the <strong> tag?

[jvoung (off chromium), 2014-05-30 21:23:57]

https://codereview.chromium.org/252023009/diff/100001/ppapi/api/ppb_messaging...
File ppapi/api/ppb_messaging.idl (right):

https://codereview.chromium.org/252023009/diff/100001/ppapi/api/ppb_messaging...
ppapi/api/ppb_messaging.idl:112: * @param[in] user_data A pointer the plugin may
choose to use when handling
comment says @param[in] for user_data, but idl says [inout]?

https://codereview.chromium.org/252023009/diff/100001/ppapi/api/ppp_message_h...
File ppapi/api/ppp_message_handler.idl (right):

https://codereview.chromium.org/252023009/diff/100001/ppapi/api/ppp_message_h...
ppapi/api/ppp_message_handler.idl:36: * @param[in] message A copy of the
parameter that JavaScript provided to
nit: comment says @param[in], but IDL says [inout] here and below?

https://codereview.chromium.org/252023009/diff/100001/ppapi/c/ppp_message_han...
File ppapi/c/ppp_message_handler.h (right):

https://codereview.chromium.org/252023009/diff/100001/ppapi/c/ppp_message_han...
ppapi/c/ppp_message_handler.h:67: struct PP_Var
(*HandleBlockingMessage)(PP_Instance instance,
I think returning by value will still be a problem for PNaCl without shims...
but maybe I'm missing something, because the shim generator didn't generate any
wrappers.

E.g., GetTouchByIndex generates a wrapper, where the first parameter is a
pointer to write/return the resulting struct.

[dmichael (off chromium), 2014-05-30 21:33:41]

On Fri, May 30, 2014 at 3:23 PM, <jvoung@chromium.org> wrote:

>
> https://codereview.chromium.org/252023009/diff/100001/
> ppapi/api/ppb_messaging.idl
> File ppapi/api/ppb_messaging.idl (right):
>
> https://codereview.chromium.org/252023009/diff/100001/
> ppapi/api/ppb_messaging.idl#newcode112
> ppapi/api/ppb_messaging.idl:112: * @param[in] user_data A pointer the
> plugin may choose to use when handling
> comment says @param[in] for user_data, but idl says [inout]?
>
> https://codereview.chromium.org/252023009/diff/100001/
> ppapi/api/ppp_message_handler.idl
> File ppapi/api/ppp_message_handler.idl (right):
>
> https://codereview.chromium.org/252023009/diff/100001/
> ppapi/api/ppp_message_handler.idl#newcode36
> ppapi/api/ppp_message_handler.idl:36: * @param[in] message A copy of the
> parameter that JavaScript provided to
> nit: comment says @param[in], but IDL says [inout] here and below?
>
> https://codereview.chromium.org/252023009/diff/100001/
> ppapi/c/ppp_message_handler.h
> File ppapi/c/ppp_message_handler.h (right):
>
> https://codereview.chromium.org/252023009/diff/100001/
> ppapi/c/ppp_message_handler.h#newcode67
> ppapi/c/ppp_message_handler.h:67: struct PP_Var
> (*HandleBlockingMessage)(PP_Instance instance,
> I think returning by value will still be a problem for PNaCl without
> shims... but maybe I'm missing something, because the shim generator
> didn't generate any wrappers.
>
> E.g., GetTouchByIndex generates a wrapper, where the first parameter is
> a pointer to write/return the resulting struct.
>
> https://codereview.chromium.org/252023009/
>
Ugh, okay. I was forgetting about returns. I guess I need to figure out a
real way to get at the shims. That, or using a PP_Var out param in the API,
which is too much of a compromise for me.

The reason they aren't generated is I updated the pnacl generator stuff to
do this for "no_interface_string", since otherwise the wrapper code won't
build:
https://codereview.chromium.org/305233002/

I think I'll still go forward with that CL (no shim generation) for now so
I can get this in without PNaCl support. Then, I can figure out the shim
stuff separately and turn on PNaCl support later.

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[jvoung (off chromium), 2014-05-30 21:50:07]

On 2014/05/30 21:33:41, dmichael wrote:
> On Fri, May 30, 2014 at 3:23 PM, <mailto:jvoung@chromium.org> wrote:
> 
> >
> > https://codereview.chromium.org/252023009/diff/100001/
> > ppapi/api/ppb_messaging.idl
> > File ppapi/api/ppb_messaging.idl (right):
> >
> > https://codereview.chromium.org/252023009/diff/100001/
> > ppapi/api/ppb_messaging.idl#newcode112
> > ppapi/api/ppb_messaging.idl:112: * @param[in] user_data A pointer the
> > plugin may choose to use when handling
> > comment says @param[in] for user_data, but idl says [inout]?
> >
> > https://codereview.chromium.org/252023009/diff/100001/
> > ppapi/api/ppp_message_handler.idl
> > File ppapi/api/ppp_message_handler.idl (right):
> >
> > https://codereview.chromium.org/252023009/diff/100001/
> > ppapi/api/ppp_message_handler.idl#newcode36
> > ppapi/api/ppp_message_handler.idl:36: * @param[in] message A copy of the
> > parameter that JavaScript provided to
> > nit: comment says @param[in], but IDL says [inout] here and below?
> >
> > https://codereview.chromium.org/252023009/diff/100001/
> > ppapi/c/ppp_message_handler.h
> > File ppapi/c/ppp_message_handler.h (right):
> >
> > https://codereview.chromium.org/252023009/diff/100001/
> > ppapi/c/ppp_message_handler.h#newcode67
> > ppapi/c/ppp_message_handler.h:67: struct PP_Var
> > (*HandleBlockingMessage)(PP_Instance instance,
> > I think returning by value will still be a problem for PNaCl without
> > shims... but maybe I'm missing something, because the shim generator
> > didn't generate any wrappers.
> >
> > E.g., GetTouchByIndex generates a wrapper, where the first parameter is
> > a pointer to write/return the resulting struct.
> >
> > https://codereview.chromium.org/252023009/
> >
> Ugh, okay. I was forgetting about returns. I guess I need to figure out a
> real way to get at the shims. That, or using a PP_Var out param in the API,
> which is too much of a compromise for me.
> 
> The reason they aren't generated is I updated the pnacl generator stuff to
> do this for "no_interface_string", since otherwise the wrapper code won't
> build:
> https://codereview.chromium.org/305233002/
> 
> I think I'll still go forward with that CL (no shim generation) for now so
> I can get this in without PNaCl support. Then, I can figure out the shim
> stuff separately and turn on PNaCl support later.
>

Okay, then otherwise LGTM

[dmichael (off chromium), 2014-05-31 16:53:07]

The CQ bit was checked by dmichael@chromium.org

[commit-bot: I haz the power, 2014-05-31 16:53:59]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/dmichael@chromium.org/252023009/140001

[commit-bot: I haz the power, 2014-05-31 20:41:43]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  chromium_presubmit on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/chromium_presubmit/bu...)
  linux_chromium_chromeos_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)
  linux_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_rel/bu...)
  mac_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)
  win_chromium_compile_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_compile_...)
  win_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...)

[commit-bot: I haz the power, 2014-05-31 20:44:32]

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

[commit-bot: I haz the power, 2014-05-31 20:44:32]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/chromium_presubmit/bu...)

[jvoung (off chromium), 2014-06-02 15:58:48]

https://codereview.chromium.org/252023009/diff/60001/ppapi/native_client/src/...
File ppapi/native_client/src/untrusted/pnacl_irt_shim/pnacl_shim.c (right):

https://codereview.chromium.org/252023009/diff/60001/ppapi/native_client/src/...
ppapi/native_client/src/untrusted/pnacl_irt_shim/pnacl_shim.c:1139: static
int32_t Pnacl_M36_PPB_Messaging_RegisterMessageHandler(PP_Instance instance,
const void* user_data, const struct PPP_MessageHandler_0_1* handler, PP_Resource
message_loop) {
One thought on how to handle this w/ shims is to modify the shim generator to do
some interception right here. That is instead of trying to have some API for
reaching into the shim.

Suppose in the IDL, you tag the PPP_MessageHandler_0_1 argument as special in
the sense that:

(a) it points to a struct of function pointers that themselves need to be
shimmed and you know the shim generator will generate the wrappers
(b) only one set of those function pointers are live at a time

Then you can copy the function pointers from handler into some static location
("real_ppp_message_handler_0_1" for example). Then set
"Pnacl_WrapperInfo_PPP_MessageHandler_0_1.real_iface" to point to that copy.

Then in the call to iface->RegisterMessageHandler(), instead of passing
"handler", pass "Pnacl_WrapperInfo_PPP_MessageHandler_0_1.wrapped_iface". The
generated wrappers for Pnacl_WrapperInfo_PPP_MessageHandler_0_1 should then
handle the rest.

Maybe it's not too clean to have to tag the IDL w/ info about shimming. You
could try to detect this situation instead, but the restriction (b) above is not
something you can just detect. Might also need to be careful if the registration
thread is different from the PPP handler thread, so don't want to be too
automatic (unless the shim code is thread safe)?

[dmichael (off chromium), 2014-06-02 16:04:17]

I think we need an approach that doesn't use a global pointer for the
functions. If we have multiple instances, they can set different function
pointers with this API. If we use this pattern again in another API, it
could even be possible for 1 instance to have multiple different
implementations for the struct.

I had hoped maybe it wouldn't be too hard to plumb an API so the proxy code
can say...  "give me a wrapper for this interface". We can use a string to
identify it if necessary. Or just know the wrapper's class name. But I
haven't tried yet.


On Mon, Jun 2, 2014 at 9:58 AM, <jvoung@chromium.org> wrote:

>
> https://codereview.chromium.org/252023009/diff/60001/
> ppapi/native_client/src/untrusted/pnacl_irt_shim/pnacl_shim.c
> File ppapi/native_client/src/untrusted/pnacl_irt_shim/pnacl_shim.c
> (right):
>
> https://codereview.chromium.org/252023009/diff/60001/
> ppapi/native_client/src/untrusted/pnacl_irt_shim/pnacl_shim.c#newcode1139
> ppapi/native_client/src/untrusted/pnacl_irt_shim/pnacl_shim.c:1139:
> static int32_t
> Pnacl_M36_PPB_Messaging_RegisterMessageHandler(PP_Instance instance,
> const void* user_data, const struct PPP_MessageHandler_0_1* handler,
> PP_Resource message_loop) {
> One thought on how to handle this w/ shims is to modify the shim
> generator to do some interception right here. That is instead of trying
> to have some API for reaching into the shim.
>
> Suppose in the IDL, you tag the PPP_MessageHandler_0_1 argument as
> special in the sense that:
>
> (a) it points to a struct of function pointers that themselves need to
> be shimmed and you know the shim generator will generate the wrappers
> (b) only one set of those function pointers are live at a time
>
> Then you can copy the function pointers from handler into some static
> location ("real_ppp_message_handler_0_1" for example). Then set
> "Pnacl_WrapperInfo_PPP_MessageHandler_0_1.real_iface" to point to that
> copy.
>
> Then in the call to iface->RegisterMessageHandler(), instead of passing
> "handler", pass
> "Pnacl_WrapperInfo_PPP_MessageHandler_0_1.wrapped_iface". The generated
> wrappers for Pnacl_WrapperInfo_PPP_MessageHandler_0_1 should then handle
> the rest.
>
> Maybe it's not too clean to have to tag the IDL w/ info about shimming.
> You could try to detect this situation instead, but the restriction (b)
> above is not something you can just detect. Might also need to be
> careful if the registration thread is different from the PPP handler
> thread, so don't want to be too automatic (unless the shim code is
> thread safe)?
>
>
> https://codereview.chromium.org/252023009/
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-reviews+unsubscribe@chromium.org.
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[dmichael (off chromium), 2014-06-02 17:02:14]

The CQ bit was checked by dmichael@chromium.org

[commit-bot: I haz the power, 2014-06-02 17:03:19]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/dmichael@chromium.org/252023009/160001

[dmichael (off chromium), 2014-06-02 17:12:30]

+binji for native_cliend_sdk

[binji, 2014-06-02 17:21:01]

native_client_sdk lgtm

[commit-bot: I haz the power, 2014-06-02 19:46:23]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  win_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...)

[commit-bot: I haz the power, 2014-06-02 22:16:46]

Change committed as 274349