IPDL now supports async returns with MozPromise

[Kan-Ru Chen]

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.

[Bevis Tseng]

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

Regards,
Bevis Tseng

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[smaug]

On 04/20/2017 05:15 AM, Bevis Tseng 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().
>

Why is using AbstractThread::MainThread() ok in background threads?

[Bevis Tseng]

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.

[Bevis Tseng]

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