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
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 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 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 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
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
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
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