| Summary: | [WebAssembly] Use StreamingParser in existing Wasm::BBQPlan | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Yusuke Suzuki <ysuzuki> | ||||||||||||
| Component: | New Bugs | Assignee: | Yusuke Suzuki <ysuzuki> | ||||||||||||
| Status: | RESOLVED FIXED | ||||||||||||||
| Severity: | Normal | CC: | ews-watchlist, keith_miller, mark.lam, msaboff, saam, Skinnermelony09, tzagallo, webkit-bug-importer | ||||||||||||
| Priority: | P2 | Keywords: | InRadar | ||||||||||||
| Version: | WebKit Nightly Build | ||||||||||||||
| Hardware: | Unspecified | ||||||||||||||
| OS: | Unspecified | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Yusuke Suzuki
2018-08-27 23:51:13 PDT
Created attachment 348269 [details]
Patch
Created attachment 348287 [details]
Patch
Created attachment 348292 [details]
Patch
I also would like to revive this patch to prepare for introducing compileStreaming / instantiateStreaming. Created attachment 376631 [details]
Patch
WIP
Created attachment 377857 [details]
Patch
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?
(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. (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. (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. Comment on attachment 377857 [details]
Patch
r=me with the name change.
(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. Committed r249708: <https://trac.webkit.org/changeset/249708> |