NaCl proxy for PPB_NetworkMonitor_Private

NaCl proxy for PPB_NetworkMonitor_Private

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

[Sergey Ulanov, 2012-08-06 19:08:03]

As we discussed this code leaks (see 
browser_ppb_network_monitor_private_rpc_server.cc), but it doesn't make sense to
fix the leak now as this code is going to be removed soon anyway. I just need it
now to enable further work on NaCl version of chromoting client.

[dmichael (off chromium), 2012-08-06 22:44:25]

Early comments. Still looking.

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
File
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_list_private_rpc_server.cc
(right):

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_list_private_rpc_server.cc:35:
rpc->result = NACL_SRPC_RESULT_OK;
We usually set result to something bad at the start of the function, like
NACL_SRPC_RESULT_APP_ERROR, and only set it to NACL_SRPC_RESULT_OK at the end,
when we've completed successfully.

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_list_private_rpc_server.cc:72:
rpc->result = NACL_SRPC_RESULT_APP_ERROR;
I think you need to release pp_string after it's serialized, or it's going to
live forever. GetName returns a reference on the var. (same anywhere else you
fetch a string PP_Var)

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
File
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_monitor_private_rpc_server.cc
(right):

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_monitor_private_rpc_server.cc:61:
// long term.
I think this is OK for a short term fix; I don't really care too much about a
leak this small in the SRPC proxy. But it makes me question the API a bit... 
have you coded up an example app? I was curious how the C++ wrapper handles
this, and apparently it doesn't. I thought maybe we had a delegate pattern there
with a virtual function or something, but it's just the same callback function
and void* user data. That doesn't seem like a very friendly C++ experience.

This seems to point out a problem in the API we should probably fix. Maybe
something like a PPB_NetworkMonitorDestroyed callback function (as I think you
suggested) is the right thing to do? Or something more general or clever that we
haven't thought of yet. But right now, we're putting the burden on the developer
to know the reference count, which is not very developer friendly.

What do you think?

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
File
ppapi/native_client/src/shared/ppapi_proxy/plugin_ppb_network_list_private.cc
(right):

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
ppapi/native_client/src/shared/ppapi_proxy/plugin_ppb_network_list_private.cc:36:
if (srpc_result != NACL_SRPC_RESULT_OK && is_network_list)
Did you mean ==?

Maybe it would be cleaner to do:
if (srpc != NACL_SRPC_RESULT_OK)
  return PP_FALSE;

return PP_FromBool(is_network_list);

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
ppapi/native_client/src/shared/ppapi_proxy/plugin_ppb_network_list_private.cc:57:
return count;
surprised you don't have to static_cast to uint32_t or anything...

[Sergey Ulanov, 2012-08-07 21:17:41]

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
File
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_list_private_rpc_server.cc
(right):

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_list_private_rpc_server.cc:35:
rpc->result = NACL_SRPC_RESULT_OK;
On 2012/08/06 22:44:25, dmichael wrote:
> We usually set result to something bad at the start of the function, like
> NACL_SRPC_RESULT_APP_ERROR, and only set it to NACL_SRPC_RESULT_OK at the end,
> when we've completed successfully.

Done.

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_list_private_rpc_server.cc:72:
rpc->result = NACL_SRPC_RESULT_APP_ERROR;
On 2012/08/06 22:44:25, dmichael wrote:
> I think you need to release pp_string after it's serialized, or it's going to
> live forever. GetName returns a reference on the var. (same anywhere else you
> fetch a string PP_Var)

No other code that uses SerializeTo() does anything with PP_Var after calling
that methods so I'm not sure if it is necessary.

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
File
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_monitor_private_rpc_server.cc
(right):

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_monitor_private_rpc_server.cc:61:
// long term.
On 2012/08/06 22:44:25, dmichael wrote:
> I think this is OK for a short term fix; I don't really care too much about a
> leak this small in the SRPC proxy. But it makes me question the API a bit... 
> have you coded up an example app? I was curious how the C++ wrapper handles
> this, and apparently it doesn't. 

Right, C++ wrapper doesn't handle this directly. The user of the interface
controls lifetime of the monitor, so it controls when the callback may be
called. That also matches what we have for PPB_Audio. We've been using this API
in the Chromoting client and it works fine.

> I thought maybe we had a delegate pattern there
> with a virtual function or something, but it's just the same callback function
> and void* user data. That doesn't seem like a very friendly C++ experience.

There is also NetworkListObserverPrivate class in utilities that host reference
to the NetworkMonitor resource and makes callbacks easier to handle.

> 
> This seems to point out a problem in the API we should probably fix. Maybe
> something like a PPB_NetworkMonitorDestroyed callback function (as I think you
> suggested) is the right thing to do? Or something more general or clever that
we
> haven't thought of yet. But right now, we're putting the burden on the
developer
> to know the reference count, which is not very developer friendly.
> 
> What do you think?

such callback might be useful, but I think it should be consistent with other
APIs. E.g. PPB_Audio also has a callback that can be called until the audio
object is destroyed - the same API change would be useful there as well.

Alternative approach (that would be easier to use) is to add Close() method that
stops the callbacks from happening even if monitor still exists. But that
wouldn't help with memory management in the proxy.

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
File
ppapi/native_client/src/shared/ppapi_proxy/plugin_ppb_network_list_private.cc
(right):

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
ppapi/native_client/src/shared/ppapi_proxy/plugin_ppb_network_list_private.cc:36:
if (srpc_result != NACL_SRPC_RESULT_OK && is_network_list)
On 2012/08/06 22:44:25, dmichael wrote:
> Did you mean ==?
> 
> Maybe it would be cleaner to do:
> if (srpc != NACL_SRPC_RESULT_OK)
>   return PP_FALSE;
> 
> return PP_FromBool(is_network_list);

Done.

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
ppapi/native_client/src/shared/ppapi_proxy/plugin_ppb_network_list_private.cc:57:
return count;
On 2012/08/06 22:44:25, dmichael wrote:
> surprised you don't have to static_cast to uint32_t or anything...

As far as I know MSVC is the only compiler that has warning for this case, and
this code is compiled only with NaCl's GCC.

[Sergey Ulanov, 2012-08-09 00:33:19]

ping

[dmichael (off chromium), 2012-08-09 03:57:27]

lgtm

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
File
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_list_private_rpc_server.cc
(right):

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_list_private_rpc_server.cc:72:
rpc->result = NACL_SRPC_RESULT_APP_ERROR;
On 2012/08/07 21:17:41, sergeyu wrote:
> On 2012/08/06 22:44:25, dmichael wrote:
> > I think you need to release pp_string after it's serialized, or it's going
to
> > live forever. GetName returns a reference on the var. (same anywhere else
you
> > fetch a string PP_Var)
> 
> No other code that uses SerializeTo() does anything with PP_Var after calling
> that methods so I'm not sure if it is necessary.
Ugh, you're right, we do this all over. I'm pretty sure that those are also
leaking (at least, PPB interfaces where we're returning a PP_Var). GetName
returns a reference (as most PP_Var getters do). The behavior would look right
to the plugin, and this wouldn't even technically be a "memory leak", but that
string is going to sit in the renderer's VarTracker for the life of the plugin.

I've filed a bug: crbug.com/141561 .  I looked, and I think the easiest way to
fix this will be within SerializeTo itself, so you might as well leave your code
as-is.

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
File
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_monitor_private_rpc_server.cc
(right):

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_monitor_private_rpc_server.cc:61:
// long term.
On 2012/08/07 21:17:41, sergeyu wrote:
> On 2012/08/06 22:44:25, dmichael wrote:
> > I think this is OK for a short term fix; I don't really care too much about
a
> > leak this small in the SRPC proxy. But it makes me question the API a bit...

> > have you coded up an example app? I was curious how the C++ wrapper handles
> > this, and apparently it doesn't. 
> 
> Right, C++ wrapper doesn't handle this directly. The user of the interface
> controls lifetime of the monitor, so it controls when the callback may be
> called. That also matches what we have for PPB_Audio. We've been using this
API
> in the Chromoting client and it works fine.
So, I looked at the C++ class in utility. One thing you should do there (Which I
missed when reviewing it) is disable the copy constructor and assignment
operator. They won't do anything reasonable. Most resources are copyable, which
is when the reference counting comes in to play. Since your wrapper owns the
resource and doesn't share it, though, it seems fine (as long as you disable
copying).

> 
> > I thought maybe we had a delegate pattern there
> > with a virtual function or something, but it's just the same callback
function
> > and void* user data. That doesn't seem like a very friendly C++ experience.
> 
> There is also NetworkListObserverPrivate class in utilities that host
reference
> to the NetworkMonitor resource and makes callbacks easier to handle.
> 
> > 
> > This seems to point out a problem in the API we should probably fix. Maybe
> > something like a PPB_NetworkMonitorDestroyed callback function (as I think
you
> > suggested) is the right thing to do? Or something more general or clever
that
> we
> > haven't thought of yet. But right now, we're putting the burden on the
> developer
> > to know the reference count, which is not very developer friendly.
> > 
> > What do you think?
> 
> such callback might be useful, but I think it should be consistent with other
> APIs. E.g. PPB_Audio also has a callback that can be called until the audio
> object is destroyed - the same API change would be useful there as well.
> 
> Alternative approach (that would be easier to use) is to add Close() method
that
> stops the callbacks from happening even if monitor still exists. But that
> wouldn't help with memory management in the proxy.
Yeah, that would be fine too. I guess I worry that users of the API might have
the same memory problem as the proxy. We can just punt for now and figure it out
later.

[Sergey Ulanov, 2012-08-09 20:14:28]

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
File
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_monitor_private_rpc_server.cc
(right):

http://codereview.chromium.org/10823187/diff/30/ppapi/native_client/src/share...
ppapi/native_client/src/shared/ppapi_proxy/browser_ppb_network_monitor_private_rpc_server.cc:61:
// long term.
On 2012/08/09 03:57:27, dmichael wrote:
> On 2012/08/07 21:17:41, sergeyu wrote:
> > On 2012/08/06 22:44:25, dmichael wrote:
> > > I think this is OK for a short term fix; I don't really care too much
about
> a
> > > leak this small in the SRPC proxy. But it makes me question the API a
bit...
> 
> > > have you coded up an example app? I was curious how the C++ wrapper
handles
> > > this, and apparently it doesn't. 
> > 
> > Right, C++ wrapper doesn't handle this directly. The user of the interface
> > controls lifetime of the monitor, so it controls when the callback may be
> > called. That also matches what we have for PPB_Audio. We've been using this
> API
> > in the Chromoting client and it works fine.
> So, I looked at the C++ class in utility. One thing you should do there (Which
I
> missed when reviewing it) is disable the copy constructor and assignment
> operator. They won't do anything reasonable. Most resources are copyable,
which
> is when the reference counting comes in to play. Since your wrapper owns the
> resource and doesn't share it, though, it seems fine (as long as you disable
> copying).
> 

I agree that would be the right thing to do. Will fix it in a separate CL.

> > 
> > > I thought maybe we had a delegate pattern there
> > > with a virtual function or something, but it's just the same callback
> function
> > > and void* user data. That doesn't seem like a very friendly C++
experience.
> > 
> > There is also NetworkListObserverPrivate class in utilities that host
> reference
> > to the NetworkMonitor resource and makes callbacks easier to handle.
> > 
> > > 
> > > This seems to point out a problem in the API we should probably fix. Maybe
> > > something like a PPB_NetworkMonitorDestroyed callback function (as I think
> you
> > > suggested) is the right thing to do? Or something more general or clever
> that
> > we
> > > haven't thought of yet. But right now, we're putting the burden on the
> > developer
> > > to know the reference count, which is not very developer friendly.
> > > 
> > > What do you think?
> > 
> > such callback might be useful, but I think it should be consistent with
other
> > APIs. E.g. PPB_Audio also has a callback that can be called until the audio
> > object is destroyed - the same API change would be useful there as well.
> > 
> > Alternative approach (that would be easier to use) is to add Close() method
> that
> > stops the callbacks from happening even if monitor still exists. But that
> > wouldn't help with memory management in the proxy.
> Yeah, that would be fine too. I guess I worry that users of the API might have
> the same memory problem as the proxy. We can just punt for now and figure it
out
> later.

[commit-bot: I haz the power, 2012-08-09 20:15:49]

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

[commit-bot: I haz the power, 2012-08-09 20:15:59]

Presubmit check for 10823187-11001 failed and returned exit status 1.


Running presubmit commit checks ...

** Presubmit Warnings **
Found lines longer than 80 characters (first 5 shown).
  ppapi/native_client/src/shared/ppapi_proxy/ppb_rpc_client.cc, line 2185, 81
chars \
  ppapi/native_client/src/shared/ppapi_proxy/ppb_rpc_client.cc, line 2276, 82
chars \
  ppapi/native_client/src/shared/ppapi_proxy/ppb_rpc_client.cc, line 2297, 82
chars \
  ppapi/native_client/src/shared/ppapi_proxy/ppb_rpc_client.cc, line 2352, 90
chars \
  ppapi/native_client/src/shared/ppapi_proxy/ppb_rpc_server.cc, line 3343, 99
chars

Presubmit checks took 2.4s to calculate.

[dmichael (off chromium), 2012-08-09 20:59:20]

Oops, you'll probably just have to git cl dcommit (assuming your trys look
green).

On Thu, Aug 9, 2012 at 2:15 PM, <[email protected]> wrote:

> Presubmit check for 10823187-11001 failed and returned exit status 1.
>
>
> Running presubmit commit checks ...
>
> ** Presubmit Warnings **
> Found lines longer than 80 characters (first 5 shown).
>   ppapi/native_client/src/**shared/ppapi_proxy/ppb_rpc_**client.cc, line
> 2185, 81
> chars \
>   ppapi/native_client/src/**shared/ppapi_proxy/ppb_rpc_**client.cc, line
> 2276, 82
> chars \
>   ppapi/native_client/src/**shared/ppapi_proxy/ppb_rpc_**client.cc, line
> 2297, 82
> chars \
>   ppapi/native_client/src/**shared/ppapi_proxy/ppb_rpc_**client.cc, line
> 2352, 90
> chars \
>   ppapi/native_client/src/**shared/ppapi_proxy/ppb_rpc_**server.cc, line
> 3343, 99
> chars
>
> Presubmit checks took 2.4s to calculate.
>
>
>
>
https://chromiumcodereview.**appspot.com/10823187/<https://chromiumcodereview...
>

[Sergey Ulanov, 2012-08-10 00:02:12]

There was also a problem with NaCl not being able to detect new files being
added. I fixed it (
http://src.chromium.org/viewvc/native_client?view=rev&revision=9414 ), but the
fix hasn't been rolled to chromium yet. To workaround it I added two noop
changes: one in test_network_monitor_private.cc and one in
plugin_ppb_tcp_socket_private.cc.


On 2012/08/09 20:59:20, dmichael wrote:
> Oops, you'll probably just have to git cl dcommit (assuming your trys look
> green).
> 
> On Thu, Aug 9, 2012 at 2:15 PM, <mailto:[email protected]> wrote:
> 
> > Presubmit check for 10823187-11001 failed and returned exit status 1.
> >
> >
> > Running presubmit commit checks ...
> >
> > ** Presubmit Warnings **
> > Found lines longer than 80 characters (first 5 shown).
> >   ppapi/native_client/src/**shared/ppapi_proxy/ppb_rpc_**client.cc, line
> > 2185, 81
> > chars \
> >   ppapi/native_client/src/**shared/ppapi_proxy/ppb_rpc_**client.cc, line
> > 2276, 82
> > chars \
> >   ppapi/native_client/src/**shared/ppapi_proxy/ppb_rpc_**client.cc, line
> > 2297, 82
> > chars \
> >   ppapi/native_client/src/**shared/ppapi_proxy/ppb_rpc_**client.cc, line
> > 2352, 90
> > chars \
> >   ppapi/native_client/src/**shared/ppapi_proxy/ppb_rpc_**server.cc, line
> > 3343, 99
> > chars
> >
> > Presubmit checks took 2.4s to calculate.
> >
> >
> >
> >
>
https://chromiumcodereview.**appspot.com/10823187/%3Chttps://chromiumcoderevi...>
> >