Re: windows build anti-virus exclusion list?

[Jeff Gilbert]

Can confirm for Ryzen: FWIW, my stock R7 1800x (RAM @2133Mhz for now
:( ) did a Windows debug clobber in 15:32.40 with the default -j16.
(any directory that showed up as read by MsMpEng in Resource Monitor
excluded for Defender)

I'll give it a run through with Defender disabled, and see if there's
any change.

On Tue, Apr 18, 2017 at 2:17 AM, Marco Bonardo  wrote:
> On Fri, Mar 17, 2017 at 7:20 PM, Ben Kelly  wrote:
>
>> On Fri, Mar 17, 2017 at 1:36 PM, Ted Mielczarek 
>> wrote:
>>
>> With defender
>> disabled the best I can get is 18min.  This is on one of the new lenovo
>> p710 machines with 16 xeon cores.
>>
>
> Just to add one datapoint, I just replaced my desktop with an AMD Ryzen
> 1700x (OC @3.8GHz) and I can clobber in less than 18mins on something that
> may be cheaper than those XEON machines (an OC 1700 can probably do the
> same). I'm currently using -J20, I didn't yet try to bump that up to see
> what's the limit, I'm positive I can get better times out of this machine,
> but I need to find some time for testing.
> I'm using Panda Free, with the SSD containing the sources in its exclusion
> list, didn't do anything to Defender (but I guess it's disabled by having
> another AV in the system).
> You can also disable Defender with a GPO, by setting "Turn off Windows
> Defender" to Enabled.
> ___
> 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: IPDL now supports async returns with MozPromise

[Bevis Tseng]

On Thu, Apr 20, 2017 at 11:13 PM, Bevis Tseng  wrote:

>
>
> On Thu, Apr 20, 2017 at 10: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
>> 
>> 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  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&& 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

Re: IPDL now supports async returns with MozPromise

[Bevis Tseng]

On Thu, Apr 20, 2017 at 10: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
>  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  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&& 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

Re: IPDL now supports async returns with MozPromise

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



Regards,
Bevis Tseng


On Thu, Apr 20, 2017 at 2:54 AM, Kan-Ru Chen  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&& 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