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