<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [JSC] implement async functions proposal"
href="https://bugs.webkit.org/show_bug.cgi?id=156147#c27">Comment # 27</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [JSC] implement async functions proposal"
href="https://bugs.webkit.org/show_bug.cgi?id=156147">bug 156147</a>
from <span class="vcard"><a class="email" href="mailto:caitp@igalia.com" title="Caitlin Potter (:caitp) <caitp@igalia.com>"> <span class="fn">Caitlin Potter (:caitp)</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=156147#c26">comment #26</a>)
<span class="quote">> > 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.</span >
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</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>