Multiple instances: intended use cases?

[Mike Acton]

What are some good, practical, non-contrived examples of needing multiple instances? It seems like it's actually expected to be the most common case since the default API is designed to force you to carry instance information around.

I'd like to be clear about the benefits to understand the value of passing around instance information all throughout an application, and in particular down to all the lower level functions that might need to post messages, rather than assuming a single global.

Mike.

[Alan Wolfe]

how would you see the API working the other way, where the default usage was a single instance with the option to have multiple?  If you have a good solution, i'd +1 it! (:

We as end users of course also have the option to do something like make a singleton and not have to deal with it in our day to day code.

I'm curious to see if anyone has a good answer to your question about practical uses of multiple instances.  Maybe the thought is that you could make a "control" type thing that could occur once or multiple times on a page, and just by virtue of the API, it ought to just work for N instances?

Mike.

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/3Fau7EpCFUEJ.
To post to this group, send email to native-cli...@googlegroups.com.
To unsubscribe from this group, send email to native-client-di...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.

[Bennet Yee (余仕斌)]

currently each embed tag creates a new sel_ldr process, each with its own module which would get a single plugin instance.  eventually, i think this might work differently, so that multiple embed tags can specify the same nmf (details unclear on how to specify distinct modules vs shared modules), so that multiple instances can be created in the same module.  the first use case that comes to mind is where one might want to let the browser handle the layout of the page, but to have multiple rectangular regions being provided by the same module.  that way, an application or game that want to have a control panel / status display separate from a main work / exterior-view region would be easier.  because NaCl modules cannot communicate with each other except by routing messages through JavaScript -- which adds latency -- the ability to essentially have two plugin instances share an address space would remove a lot of overhead.

-bsy

--
bennet s yee
i usually don't capitalize due to mild tendonitis

[Brett Wilson]

On Sun, Apr 22, 2012 at 3:49 AM, Mike Acton <mac...@gmail.com> wrote:

> What are some good, practical, non-contrived examples of needing multiple
> instances? It seems like it's actually expected to be the most common case
> since the default API is designed to force you to carry instance information
> around.

HIstorically all plugins use this model. Imagine if Flash or QuickTime
had to start another process for every time there was an instance on
the page. The Pepper version of Flash does this (it doesn't use Native
Client, as Bennet pointed out, NaCl doesn't support this yet).

Brett

[Mike Acton]

how would you see the API working the other way, where the default usage was a single instance with the option to have multiple?  If you have a good solution, i'd +1 it! (:

I'm sure there are lots of better solutions to this, but here's what occurs to me first:

• Remove the module interface. That's largely useless anyway, as far as I can tell. 
• Use the API precedent already set by OpenGLES:
• An "Instance Context" is set by default by whatever calls the instance entry point, although the instance id is passed in as well.
• Under normal conditions that instance id would be unused by the application.
• Pass the browser interface in to the instance entry point. But the same caller also sets these to global "context"
• Under normal conditions that browser interface would also be ignored by the application.
• There are wrapper functions for all the interfaces (ideally inline in the header you don't have to pay for an additional function indirection.)
• Each wrapper calls the appropriate interface using the global "instance context" set by default. No passing around stuff.  
• If you wanted an app with multiple instances, you'd use the interfaces and not the wrapper functions and use the values passed in to the instance entry point.

Of course there's nothing to stop us from doing this, but since there isn't a standard method, everyone's API is going to look slightly different and that's a lot of duplicated work across all devs.

Mike.

[Mike Acton]

HIstorically all plugins use this model. Imagine if Flash or QuickTime
had to start another process for every time there was an instance on
the page. The Pepper version of Flash does this (it doesn't use Native
Client, as Bennet pointed out, NaCl doesn't support this yet).

Right. But to me this hardly seems the most common case for NaCl apps? The expectation, I assume, is that most of the time NaCl plugins will be providing the actual specific code someone wants to run and not an engine for running interpreted code/data, which is the only practical model for plugins currently. That seems like one of the major advantages of NaCl.

However, if one was going to write an engine-type plugin and expect all the application code to remain in javascript or pre-built script or something, I can see how the multiple instances would be useful. But why is it the default API? Was this type of use actually intended to be the main case? Because that's what the API is communicating, at least to me.

Mike.

[Mike Acton]

Of course there's nothing to stop us from doing this, but since there isn't a standard method, everyone's API is going to look slightly different and that's a lot of duplicated work across all devs.

Along these lines, I generated code from the Pepper 18 API that:

• Provides equivalent functions (a la OpenGLES) to all the API calls but presumes only one instance. For my common case of only one instance. 
  
• All the forwarding calls are inline.
• Does the boilerplate module loading and PPB hookup. 
• Minus the PP_Instance parameters, all the other parameters are identical.

In case anyone else has the same case and wants to just get rolling quicker.

github: hello_01_single_instance 

• The generated header: nacl.h 
  
• And nacl.c which does the boilerplate module stuff: nacl.c
  
• The app just includes those two files and provides all the expected entry points. e.g. hello.c 

Mike.

[David Michael]

On Sun, Apr 22, 2012 at 2:25 PM, Mike Acton <mac...@gmail.com> wrote:

HIstorically all plugins use this model. Imagine if Flash or QuickTime
had to start another process for every time there was an instance on
the page. The Pepper version of Flash does this (it doesn't use Native
Client, as Bennet pointed out, NaCl doesn't support this yet).

Right. But to me this hardly seems the most common case for NaCl apps? The expectation, I assume, is that most of the time NaCl plugins will be providing the actual specific code someone wants to run and not an engine for running interpreted code/data, which is the only practical model for plugins currently. That seems like one of the major advantages of NaCl.

However, if one was going to write an engine-type plugin and expect all the application code to remain in javascript or pre-built script or something, I can see how the multiple instances would be useful. But why is it the default API?

Partly historical reasons, partly resource constraints, and partly because we think it's the right thing to do.

-Historical: Pepper is a browser plugin API; it needs to work for existing plugins like Flash (and we do use it for that).

-Resource constraints: We already are maintaining two versions of the APIs (C and C++), along with a lot of internal baggage for each interface. We don't have time to support yet another dimension of API.

-Right thing to do: Eventually, we might support multiple instances per-process in NaCl. It could be useful for more than just a platform-style plugin (as Bennet notes, you might want to draw to >1 rectangle for your app. Maybe one of them uses openGL and one of them uses 2D, for example.) If we started out supporting only the 1 instance model, it would be a lot harder to add support for multiple instances. Associating an instance with your app also will make it easier for us to manage multiple threads accessing pepper and proper shutdown semantics.

Was this type of use actually intended to be the main case? Because that's what the API is communicating, at least to me.

Mike.

--

[David Michael]

On Wed, Oct 31, 2012 at 1:16 PM, Alexandre Barreira <abar...@gmail.com> wrote:

Hi there,

Any news on this matter? Having a module handling several instances would actually be very useful for what I'm currently trying to do..

It's not in our immediate plans. We're trying to not code ourselves in to a hole so we can add it later, but I really can't give any kind of estimate when it would be done.

Cheers,

Alexandre

On Sunday, April 22, 2012 8:02:44 PM UTC+2, Bennet Yee wrote:

currently each embed tag creates a new sel_ldr process, each with its own module which would get a single plugin instance.  eventually, i think this might work differently, so that multiple embed tags can specify the same nmf (details unclear on how to specify distinct modules vs shared modules), so that multiple instances can be created in the same module.  the first use case that comes to mind is where one might want to let the browser handle the layout of the page, but to have multiple rectangular regions being provided by the same module.  that way, an application or game that want to have a control panel / status display separate from a main work / exterior-view region would be easier.  because NaCl modules cannot communicate with each other except by routing messages through JavaScript -- which adds latency -- the ability to essentially have two plugin instances share an address space would remove a lot of overhead.

-bsy

On Sun, Apr 22, 2012 at 10:41 AM, Alan Wolfe <alan....@gmail.com> wrote:

how would you see the API working the other way, where the default usage was a single instance with the option to have multiple?  If you have a good solution, i'd +1 it! (:

We as end users of course also have the option to do something like make a singleton and not have to deal with it in our day to day code.

I'm curious to see if anyone has a good answer to your question about practical uses of multiple instances.  Maybe the thought is that you could make a "control" type thing that could occur once or multiple times on a page, and just by virtue of the API, it ought to just work for N instances?

On Sun, Apr 22, 2012 at 3:49 AM, Mike Acton <mac...@gmail.com> wrote:

What are some good, practical, non-contrived examples of needing multiple instances? It seems like it's actually expected to be the most common case since the default API is designed to force you to carry instance information around.

I'd like to be clear about the benefits to understand the value of passing around instance information all throughout an application, and in particular down to all the lower level functions that might need to post messages, rather than assuming a single global.

Mike.

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/3Fau7EpCFUEJ.

To post to this group, send email to native-cli...@googlegroups.com.

To unsubscribe from this group, send email to native-client-discuss+unsub...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To post to this group, send email to native-cli...@googlegroups.com.

To unsubscribe from this group, send email to native-client-discuss+unsub...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.

--
bennet s yee
i usually don't capitalize due to mild tendonitis

--

You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/8GKqIOKI5b8J.