On Thu, Apr 20, 2017 at 11:13 PM, Bevis Tseng <bts...@mozilla.com> wrote:
> > > On Thu, Apr 20, 2017 at 10:15 AM, Bevis Tseng <bts...@mozilla.com> wrote: > >> A soft reminder of using AbstractThread::GetCurrent()/MainThread() >> after some design change for Quantum-DOM. >> >> If this message/callback is to be handled on *the main thread of the >> content process*, please use the replacement called AbstractMainThreadFor >> <https://wiki.mozilla.org/Quantum/DOM#AbstractThread::MainThread> >> instead. >> >> If you're in background thread or not in content process, you are totally >> fine to use AbstractThread::GetCurrent()/MainThread(). >> >> Note: Precisely speaking, AbstractThread::MainThread() can be used in > the main thread of chrome process instead. > It shall never been used in background thread. Hope it was not misleading > in previous email. > I should say that AbstractThread::MainThread() can be used for to dispatch runnables to the main thread in chrome process. P.S. No more explanation at midnight to make thing worse. :/ Regards, >> Bevis Tseng >> >> >> On Thu, Apr 20, 2017 at 2:54 AM, Kan-Ru Chen <kc...@mozilla.com> wrote: >> >>> Hello! >>> >>> With bug 1313200 landed, async IPC messages can now return data via >>> MozPromises. >>> >>> The IPDL syntax: >>> >>> protocol PFoo { >>> child: >>> async Bar() returns (bool param); >>> }; >>> >>> will generate IPC code that allow the send method like this: >>> >>> SendBar()->Then(AbstractThread::GetCurrent(), __func__, >>> [](bool param) { >>> // do something >>> }, >>> [](PromiseRejectReason aReason) { >>> // handle send failure >>> }); >>> >>> For a message named Foo it will receive a promise resolver with type >>> FooPromise. For example the receiving side of previous message >>> PFoo::Bar the handler looks like this: >>> >>> mozilla::ipc::IPCResult >>> FooChild::RecvBarMessage(RefPtr<BarMessagePromise>&& aPromise) >>> { >>> bool result; >>> // do some computation >>> aPromise->Resolve(result); >>> } >>> >>> If there are multiple return values, they will be wrapped in a >>> mozilla::Tuple. >>> >>> The usual MozPromise rule applies. You can store the promise and >>> resolve it later. You can direct the ThenFunction to be run on other >>> threads. If the channel is closed before all promises are resolved, >>> the pending promises will be rejected with >>> PromiseRejectReason::ChannelClosed. Promises resolved after channel >>> close are ignored. >>> >>> It is discouraged for the receiving handler to reject the promise. It >>> should be reserved for the IPC system to signal errors. If you must >>> reject the promise, only PromiseRejectReason::HandlerRejected is valid >>> value. >>> >>> Please give it a try. In theory this should work for all IPC actors. If >>> you encountered issues or have ideas to >>> improve this, please file a bug in Core :: IPC. >>> >>> Thanks, >>> Kanru >>> >>> P.S. Note that async constructor or destructor does not support return >>> promises because the semantic is still not clear. >>> _______________________________________________ >>> 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
