Bug 189043 – [WebAssembly] Use StreamingParser in existing Wasm::BBQPlan

• Component: New Bugs
• Status: RESOLVED FIXED

[Yusuke Suzuki]

[WebAssembly] Use StreamingParser in existing Wasm::BBQPlan

[Yusuke Suzuki]

Created attachment 348269 [details]
Patch

[Yusuke Suzuki]

Created attachment 348287 [details]
Patch

[Yusuke Suzuki]

Created attachment 348292 [details]
Patch

[Yusuke Suzuki]

I also would like to revive this patch to prepare for introducing compileStreaming / instantiateStreaming.

[Yusuke Suzuki]

Created attachment 376631 [details]
Patch

WIP

[Yusuke Suzuki]

Created attachment 377857 [details]
Patch

[Keith Miller]

Comment on attachment 377857 [details]
Patch

The phrasing of the callback names is a little weird. didParseFunction makes it seem like it's either a query (i.e. has this function already been parsed) or that the caller already parsed the function and is informing the client it has been parsed. Is the expectation that the callbacks are invoked when the relevant bytes are available? If so, what do you think of changing the names to provide<Thing> e.g. provideFunction?

[Yusuke Suzuki]

(In reply to Keith Miller from comment #7)
> Comment on attachment 377857 [details]
> Patch
> 
> The phrasing of the callback names is a little weird. didParseFunction makes
> it seem like it's either a query (i.e. has this function already been
> parsed) or that the caller already parsed the function and is informing the
> client it has been parsed. Is the expectation that the callbacks are invoked
> when the relevant bytes are available? If so, what do you think of changing
> the names to provide<Thing> e.g. provideFunction?

This naming convention is following the naming convention of this type of callback clients in WebCore.
For example, WebCore::ResourceHandleClient is a client of ResourceHandle, and its virtual functions are invoked when ResourceHandle gets some state. And the methods of ResourceHandleClient are like,

didSendData
didReceiveData
didFinishLoading

In WebCore, this type of clients are having methods like `didXXX` or `willXXX`. Here, I'm aligning the names to WebCore's naming convention for consistency.

[Keith Miller]

(In reply to Yusuke Suzuki from comment #8)
> (In reply to Keith Miller from comment #7)
> > Comment on attachment 377857 [details]
> > Patch
> > 
> > The phrasing of the callback names is a little weird. didParseFunction makes
> > it seem like it's either a query (i.e. has this function already been
> > parsed) or that the caller already parsed the function and is informing the
> > client it has been parsed. Is the expectation that the callbacks are invoked
> > when the relevant bytes are available? If so, what do you think of changing
> > the names to provide<Thing> e.g. provideFunction?
> 
> This naming convention is following the naming convention of this type of
> callback clients in WebCore.
> For example, WebCore::ResourceHandleClient is a client of ResourceHandle,
> and its virtual functions are invoked when ResourceHandle gets some state.
> And the methods of ResourceHandleClient are like,
> 
> didSendData
> didReceiveData
> didFinishLoading
> 
> In WebCore, this type of clients are having methods like `didXXX` or
> `willXXX`. Here, I'm aligning the names to WebCore's naming convention for
> consistency.

If we want to stay consistent with WebCore's naming can we call it didReceiveFunctionData, didReceiveSectionData, etc? The current naming makes it sound like the parsing of the function has already happened when the function is called.

[Yusuke Suzuki]

(In reply to Keith Miller from comment #9)
> (In reply to Yusuke Suzuki from comment #8)
> > (In reply to Keith Miller from comment #7)
> > > Comment on attachment 377857 [details]
> > > Patch
> > > 
> > > The phrasing of the callback names is a little weird. didParseFunction makes
> > > it seem like it's either a query (i.e. has this function already been
> > > parsed) or that the caller already parsed the function and is informing the
> > > client it has been parsed. Is the expectation that the callbacks are invoked
> > > when the relevant bytes are available? If so, what do you think of changing
> > > the names to provide<Thing> e.g. provideFunction?
> > 
> > This naming convention is following the naming convention of this type of
> > callback clients in WebCore.
> > For example, WebCore::ResourceHandleClient is a client of ResourceHandle,
> > and its virtual functions are invoked when ResourceHandle gets some state.
> > And the methods of ResourceHandleClient are like,
> > 
> > didSendData
> > didReceiveData
> > didFinishLoading
> > 
> > In WebCore, this type of clients are having methods like `didXXX` or
> > `willXXX`. Here, I'm aligning the names to WebCore's naming convention for
> > consistency.
> 
> If we want to stay consistent with WebCore's naming can we call it
> didReceiveFunctionData, didReceiveSectionData, etc? The current naming makes
> it sound like the parsing of the function has already happened when the
> function is called.

Sounds nice. I'll change the names to didReceiveFunctionData, didReceiveSectionData.

[Keith Miller]

Comment on attachment 377857 [details]
Patch

r=me with the name change.

[Yusuke Suzuki]

(In reply to Keith Miller from comment #11)
> Comment on attachment 377857 [details]
> Patch
> 
> r=me with the name change.

Thanks, I'll land with name change.

[Yusuke Suzuki]

Committed r249708: <https://trac.webkit.org/changeset/249708>

[Radar WebKit Bug Importer]

<rdar://problem/55216526>