Announcing thread support in Pepper for Chrome 25

321 views
Skip to first unread message

David Michael

unread,
Feb 22, 2013, 5:01:52 PM2/22/13
to native-cli...@googlegroups.com
Hi everyone,

As we've announced previously, we’ve switched over to a new Pepper proxy as of Chrome 25. One of our reasons for this switch was so that we could support Pepper calls from any thread, including blocking calls. This functionality is now available in Chrome 25 (just promoted to stable) and the pepper_25 NaCl SDK.

This allows you to implement many things much more simply than before, because:

  • Your application can call any PPB Pepper function from any thread. No more need to bounce all your calls through pp::Core::CallOnMainThread.
  • Your application can call OpenGL functions from any thread (as long as it’s always the same thread where the context is current).
  • Your application can make Pepper calls block using pp::BlockUntilComplete. This means for many functions that were previously asynchronous-only, you can now call them synchronously (but only from background threads; this is still disallowed from the main pepper thread). The FileIO example in the SDK has been updated to demonstrate this.
  • With pp::MessageLoop there is now a simple, standard mechanism for equipping background threads with an event loop and posting work to them. See the MessageLoop documentation for more detail.
  • Asynchronous completion callbacks can be invoked on your background thread. In particular, they will run on the same thread where you invoked the associated PPB function. See the MessageLoop and CompletionCallback documentation for more detail.

There are a few caveats:
  • As always, your application should avoid blocking the main Pepper thread. In the current architecture, all incoming calls to your application still are dispatched by the main thread even if they are going to run on a non-main thread, so the main thread must be available to service calls.
  • PPP interface calls (such as HandleMessage and HandleInputEvent) are always invoked on the main Pepper thread. We may change this in the future, but it will require API changes.
  • pp::CompletionCallbackFactory is not 100% thread-safe. Refer to the documentation to make sure you are using it safely.

Please give the new feature a test-drive and let us know what you think. We hope this makes developing for Native Client more fun and productive.
-Dave

PS: If you want some of the nitty-gritty details of how this feature works, see this informal design document.

Alan Wolfe

unread,
Feb 23, 2013, 11:30:01 PM2/23/13
to native-cli...@googlegroups.com
Rad!

How's the performance compare doing it this new way vs the old way?
Is it comparable (ie is it doing similar things as call on main thread
in background?)

Thanks for the awesome news David!
> --
> You received this message because you are subscribed to the Google Groups
> "Native-Client-Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to native-client-di...@googlegroups.com.
> To post to this group, send email to native-cli...@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/native-client-discuss?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

David Michael

unread,
Feb 25, 2013, 11:48:35 AM2/25/13
to Mark Seaborn, native-cli...@googlegroups.com



On Sun, Feb 24, 2013 at 11:28 AM, Mark Seaborn <msea...@chromium.org> wrote:
On 22 February 2013 14:01, David Michael <dmic...@chromium.org> wrote:

PS: If you want some of the nitty-gritty details of how this feature works, see this informal design document.

That link gives me "You need permission to access this published document."
Thanks for pointing that out. I had to copy it to a different doc to be able to make it public. Here's the new link:
 


Mark


David Michael

unread,
Feb 25, 2013, 12:06:04 PM2/25/13
to native-cli...@googlegroups.com
On Sat, Feb 23, 2013 at 9:30 PM, Alan Wolfe <alan....@gmail.com> wrote:
Rad!

How's the performance compare doing it this new way vs the old way?
There is a little bit of a penalty for all your outbound calls, regardless of thread, because all Pepper calls acquire a lock. If the lock is uncontested (which is always the case for any existing apps, where only one thread could make calls), the penalty is negligible.
 
Is it comparable (ie is it doing similar things as call on main thread
in background?)
It's probably similar, but I honestly haven't benchmarked that kind of comparison. Calling from a background thread should be very similar in performance to calling from the main thread. In the new proxy in 25, all outgoing calls will follow the same code path. This includes posting a task to our separate message-sending thread (we call the IO thread).

Incoming calls to your plugin (like completion callbacks) will be a bit slower going to background threads, as they always pass through the main thread.

I think it's best not to think of this as a way to speed up your plugin but instead as a way to make your multithreaded Pepper code a lot more straightforward to write and maintain.

Alan Wolfe

unread,
Feb 25, 2013, 3:12:00 PM2/25/13
to native-cli...@googlegroups.com
gotcha, thanks for the info and the detailed document!
Reply all
Reply to author
Forward
0 new messages