Re: [v8-users] d8 needs a function similar to JSC's `drainMicrotasks()`

2016-05-19 Thread Adam Klein
The assertOptimized approach seems like a good balance to me of: 1. Avoiding duplicating the assertion helpers and 2. Avoiding broadening d8's runtime environment Then the only other requirement is that the usage of assertAsync (or whatever it's called) in tests isn't affected by the concerns abo

Re: [v8-users] d8 needs a function similar to JSC's `drainMicrotasks()`

2016-05-18 Thread 'Andreas Rossberg' via v8-users
On 17 May 2016 at 18:29, Caitlin Potter wrote: > Fair point, using eval/new Function could work around it. Still, it’s > unclear why these problems are acceptable(?) in a runtime function, but not > in a more general test utility > Because a runtime function isn't exposed to the world. It is alr

Re: [v8-users] d8 needs a function similar to JSC's `drainMicrotasks()`

2016-05-17 Thread Jakob Kummerow
I agree that silent nops are bad, and that's not what we have: The implementation is try { OptimizationStatusImpl = new Function( "fun", "sync", "return %GetOptimizationStatus(fun, sync);"); } catch (e) { throw new Error("natives syntax not allowed");

Re: [v8-users] d8 needs a function similar to JSC's `drainMicrotasks()`

2016-05-17 Thread Michael Starzinger
On Tue, May 17, 2016 at 6:25 PM, Jakob Kummerow wrote: > On Tue, May 17, 2016 at 1:01 AM, Caitlin Potter > wrote: > >> As part of the async functions runtime implementation, I had implemented >> a function in d8.cc which would call isolate->RunMicrotasks() --- but was >> talked down from doing t

Re: [v8-users] d8 needs a function similar to JSC's `drainMicrotasks()`

2016-05-17 Thread Caitlin Potter
Fair point, using eval/new Function could work around it. Still, it’s unclear why these problems are acceptable(?) in a runtime function, but not in a more general test utility > On May 17, 2016, at 12:25 PM, Jakob Kummerow wrote: > > On Tue, May 17, 2016 at 1:01 AM, Caitlin Potter

Re: [v8-users] d8 needs a function similar to JSC's `drainMicrotasks()`

2016-05-17 Thread Jakob Kummerow
On Tue, May 17, 2016 at 1:01 AM, Caitlin Potter wrote: > As part of the async functions runtime implementation, I had implemented a > function in d8.cc which would call isolate->RunMicrotasks() --- but was > talked down from doing this because of a worry that it might interfere with > certain use

Re: [v8-users] d8 needs a function similar to JSC's `drainMicrotasks()`

2016-05-17 Thread Caitlin Potter
It's not clear to me how this is any different from the %RunMicrotasks() runtime function (which has identical code). Can you elaborate on how the presence of the method in d8 (or, the presence of %RunMicrotasks() with --allow-natives-syntax) could break implementation code or user code? On Tu

Re: [v8-users] d8 needs a function similar to JSC's `drainMicrotasks()`

2016-05-17 Thread 'Andreas Rossberg' via v8-users
The problem with runMicrotasks is that it violates the asynchronicity invariant and the handler ordering semantics of the language. Worse, it makes running the microtask queue reentrant all of a sudden. It's unclear to me what the implications of this are, and I can't immediately convince myself th

[v8-users] d8 needs a function similar to JSC's `drainMicrotasks()`

2016-05-16 Thread Caitlin Potter
As part of the async functions runtime implementation, I had implemented a function in d8.cc which would call isolate->RunMicrotasks() --- but was talked down from doing this because of a worry that it might interfere with certain uses of d8 out in the wild. So, I went with using the existing %