[Webkit-unassigned] [Bug 156147] [JSC] implement async functions proposal

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=156147

--- Comment #27 from Caitlin Potter (:caitp) <caitp at igalia.com> ---
(In reply to comment #26)
> > I agree whole-heartedly that a flag would be beneficial :) What I meant was,
> > currently there's no apparent mechanism for attaching the RuntimeFlags class
> > to the Parser (or the VM object, somewhat surprisingly). So, it looks like
> > it would be a quicker fix to add a compile-time flag.
> 
> It looks like the current API stores RuntimeFlags on the JSGlobalObject. So,
> we can pass them through from the global object to the parser.
> 
> > The mechanism for adding runtime flags to the parser is a bit important, for
> > example if multiple tests are run using the same VM asynchronously, some may
> > depend on different sets of flags (a situation which affects V8's C++
> > tests). It may be possible to just pass in a flags option, but I'm not sure
> > if the Parser is directly exposed to the API, or what.
> 
> I don't think we need to worry about multiple tests using the same VM
> concurrently. We do concurrency for workers by allocating a new VM per
> thread, and we do concurrency in unit testing at the process level.
> 
> I believe we create a new Parser for each parsing operation. I would assign
> flags to the Parser from the global object at Parser creation time.

I've been looking at doing this --- there are some unfortunate side affects (growing the size of every UnlinkedFunctionExecutable, for one).

Is there any good reason not to just use JSC_OPTIONS for this? This would make it easy to enable during tests, without growing a bunch of classes

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160407/11d4f02b/attachment.html>