<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#c26">Comment # 26</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:ggaren@apple.com" title="Geoffrey Garen <ggaren@apple.com>"> <span class="fn">Geoffrey Garen</span></a>
</span></b>
<pre><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.</span >
It looks like the current API stores RuntimeFlags on the JSGlobalObject. So, we can pass them through from the global object to the parser.
<span class="quote">> 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.</span >
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.</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>