WorkerRef classes

Hi all,

I want to introduce a new way to deal with Web Workers that makes their
lifetime management easier to understand and to use.

In bug 1436784 I implemented a ref-counting approach for Web Workers. This
is meant to replace WorkerHolder and WorkerPrivate raw pointers.

If you want to play with Web Workers, now you have 3 new classes, each one
for a different scenario.

StrongWorkerRef - ref-counted object, non-thread-safe.  You can pass a
callback to the CTOR in order to notified when the Web Worker starts the
shutdown procedure. To obtain a WorkerPrivate, just call its Private()
method.
Keeping this object alive means keeping the Web Worker thread alive.
Note that the Web Worker can start the shutdown procedure at any time.
After the shutdown notification, no more WorkerRunnable objects will be
scheduled and no JS code will be executed on that Web Worker thread. But
having a StrongWorkerRef object allows you to dispatch
WorkerControlRunnables and to have access to WorkerPrivate safely.

WeakWorkerRef - a ref-counted object, non-thread-safe. Also here you can
pass a callback to the CTOR in order to notified when the Web Worker starts
the shutdown procedure.
>From this object, you can obtain a WorkerPrivate pointer calling:
GetPrivate(). This returns a nullptr if the Web Worker is already gone.
If you are familiar with WorkerHolder, this is similar to its
AllowIdleShutdownStart behavior.

ThreadSafeWorkerRef - ref-counted thread-safe object. Built on top of
StrongWorkerRef, it doesn't support  notification callbacks, but it can be
sent to any thread. It keeps the Web Worker alive. To obtain a
WorkerPrivate, just call its Private() method.
This is meant to be used in code that can be sent cross-threads.

More documentation can be found here:
https://hg.mozilla.org/integration/mozilla-inbound/file/tip/dom/workers/WorkerRef.h#l18
0
Andrea
3/14/2018 9:42:07 AM
mozilla.dev.platform 6359 articles. 0 followers. Post Follow

0 Replies
65 Views

Similar Articles

[PageSpeed] 19

Reply: