MozPromises are now in XPCOM
I gave a lightning talk at Whistler about MozPromise and a few other new tools to facilitate asynchronous and parallel programming in Gecko. There was significant interest, and so I spent some time over the past few weeks untangling them from dom/media and hoisting them into xpcom/. Bug 1188976 has now landed on mozilla-central, MozPromise (along with TaskQueue, AbstractThread, SharedThreadPool, and StateMirroring) can now be used everywhere in Gecko. I also just published a blog post describing why MozPromises are great and how they work: http://bholley.net/blog/2015/mozpromise.html Feedback is welcome. These tools are intended to allow developers to easily and safely run code on off-main-thread thread pools, which is something we urgently need to do more of in Gecko. Go forth and write more parallel code! bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
On Tue, Aug 18, 2015, at 11:17 PM, Bobby Holley wrote: > I gave a lightning talk at Whistler about MozPromise and a few other new > tools to facilitate asynchronous and parallel programming in Gecko. There > was significant interest, and so I spent some time over the past few > weeks > untangling them from dom/media and hoisting them into xpcom/. This looks fantastic! Having dealt with threading in C++ Gecko code in the past it's great to see tooling being built to alleviate some of the overhead and reduce the potential for bugs. Great work! -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
Hi bholley,
looks great, but a question
The example
mProducer->RequestFoo()
->Then(mThread, __func__,
[...] (ResolveType aVal) { ... },
[...] (RejectType aVal) { ... });
uses C++ lambdas. Do we have some static analysis or such in place to protect
that
lambdas don't refer to raw pointer variables in the scope
(especially raw pointer variables pointing to ref counted objects)?
Or does MozPromise have similar setup to bug 1153295 or what?
-Olli
On 08/19/2015 06:17 AM, Bobby Holley wrote:
I gave a lightning talk at Whistler about MozPromise and a few other new
tools to facilitate asynchronous and parallel programming in Gecko. There
was significant interest, and so I spent some time over the past few weeks
untangling them from dom/media and hoisting them into xpcom/.
Bug 1188976 has now landed on mozilla-central, MozPromise (along with
TaskQueue, AbstractThread, SharedThreadPool, and StateMirroring) can now be
used everywhere in Gecko.
I also just published a blog post describing why MozPromises are great and
how they work: http://bholley.net/blog/2015/mozpromise.html
Feedback is welcome. These tools are intended to allow developers to easily
and safely run code on off-main-thread thread pools, which is something we
urgently need to do more of in Gecko. Go forth and write more parallel code!
bholley
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
We have a static analysis for this right now:
https://dxr.mozilla.org/mozilla-central/source/build/clang-plugin/tests/TestNoRefcountedInsideLambdas.cpp
And there is potential for more static analyses if we decide that we
need them.
We also have bug 1157788 if we decide at some point that we want to
forbid default captures in lambdas and require explicitly listing the
capture variables.
- Michael
On 2015-08-19 8:35 AM, smaug wrote:
Hi bholley,
looks great, but a question
The example
mProducer->RequestFoo()
->Then(mThread, __func__,
[...] (ResolveType aVal) { ... },
[...] (RejectType aVal) { ... });
uses C++ lambdas. Do we have some static analysis or such in place to
protect that
lambdas don't refer to raw pointer variables in the scope
(especially raw pointer variables pointing to ref counted objects)?
Or does MozPromise have similar setup to bug 1153295 or what?
-Olli
On 08/19/2015 06:17 AM, Bobby Holley wrote:
I gave a lightning talk at Whistler about MozPromise and a few other new
tools to facilitate asynchronous and parallel programming in Gecko.
There
was significant interest, and so I spent some time over the past few
weeks
untangling them from dom/media and hoisting them into xpcom/.
Bug 1188976 has now landed on mozilla-central, MozPromise (along with
TaskQueue, AbstractThread, SharedThreadPool, and StateMirroring) can
now be
used everywhere in Gecko.
I also just published a blog post describing why MozPromises are
great and
how they work: http://bholley.net/blog/2015/mozpromise.html
Feedback is welcome. These tools are intended to allow developers to
easily
and safely run code on off-main-thread thread pools, which is
something we
urgently need to do more of in Gecko. Go forth and write more
parallel code!
bholley
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
On Tue, Aug 18, 2015 at 8:17 PM, Bobby Holley wrote: > I gave a lightning talk at Whistler about MozPromise and a few other new > tools to facilitate asynchronous and parallel programming in Gecko. There > was significant interest, and so I spent some time over the past few weeks > untangling them from dom/media and hoisting them into xpcom/. > > Bug 1188976 has now landed on mozilla-central, MozPromise (along with > TaskQueue, AbstractThread, SharedThreadPool, and StateMirroring) can now be > used everywhere in Gecko. > > I also just published a blog post describing why MozPromises are great and > how they work: http://bholley.net/blog/2015/mozpromise.html > > Feedback is welcome. These tools are intended to allow developers to easily > and safely run code on off-main-thread thread pools, which is something we > urgently need to do more of in Gecko. Go forth and write more parallel code! > > bholley > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform Does MozPromise have the same "skipping the event loop" behavior that JS promises have? Or is that limited just to StateMirroring? - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
On Wed, Aug 19, 2015 at 1:39 PM, Kyle Huey wrote: > Does MozPromise have the same "skipping the event loop" behavior that > JS promises have? They do not. > Or is that limited just to StateMirroring? > Correct, as well as StateWatching. StateMirroring uses StableState to dispatch the atomic state updates, and StateWatching uses it to run notifications. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
On Wed, Aug 19, 2015 at 2:04 PM, Bobby Holley wrote: > On Wed, Aug 19, 2015 at 1:39 PM, Kyle Huey wrote: >> >> Does MozPromise have the same "skipping the event loop" behavior that >> JS promises have? > > > They do not. > >> >> Or is that limited just to StateMirroring? > > > Correct, as well as StateWatching. StateMirroring uses StableState to > dispatch the atomic state updates, and StateWatching uses it to run > notifications. > > bholley > Good. This should be clearly documented, as its a subtle but important distinction from JS promises, which people are likely to be familiar with. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
On Wed, Aug 19, 2015 at 2:12 PM, Kyle Huey wrote: > On Wed, Aug 19, 2015 at 2:04 PM, Bobby Holley > wrote: > > On Wed, Aug 19, 2015 at 1:39 PM, Kyle Huey wrote: > >> > >> Does MozPromise have the same "skipping the event loop" behavior that > >> JS promises have? > > > > > > They do not. > > > >> > >> Or is that limited just to StateMirroring? > > > > > > Correct, as well as StateWatching. StateMirroring uses StableState to > > dispatch the atomic state updates, and StateWatching uses it to run > > notifications. > > > > bholley > > > > Good. This should be clearly documented, as its a subtle but > important distinction from JS promises, which people are likely to be > familiar with. > Done: https://hg.mozilla.org/integration/mozilla-inbound/rev/db24d3cda834 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MozPromises are now in XPCOM
On Wed, Aug 19, 2015 at 5:23 PM, Bobby Holley wrote: > On Wed, Aug 19, 2015 at 2:12 PM, Kyle Huey wrote: >> >> On Wed, Aug 19, 2015 at 2:04 PM, Bobby Holley >> wrote: >> > On Wed, Aug 19, 2015 at 1:39 PM, Kyle Huey wrote: >> >> >> >> Does MozPromise have the same "skipping the event loop" behavior that >> >> JS promises have? >> > >> > >> > They do not. >> > >> >> >> >> Or is that limited just to StateMirroring? >> > >> > >> > Correct, as well as StateWatching. StateMirroring uses StableState to >> > dispatch the atomic state updates, and StateWatching uses it to run >> > notifications. >> > >> > bholley >> > >> >> Good. This should be clearly documented, as its a subtle but >> important distinction from JS promises, which people are likely to be >> familiar with. > > > Done: https://hg.mozilla.org/integration/mozilla-inbound/rev/db24d3cda834 > <3 - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
