fix(wasip2): export _initialize#4490
Conversation
|
ran same scenario as in #4482 Before With this PR 🎉 |
aykevl
left a comment
There was a problem hiding this comment.
With this change, if wasi:cli/run@0.2.0#run is called, the package initializers will be called twice. I don't think that's the intention?
how about 03d535d ? |
|
/cc @ydnar |
|
Looking at tests, it does not look like |
03d535d to
e3e59dd
Compare
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
e3e59dd to
0d11be7
Compare
|
Reworked the PR a bit - initialization is now done always, but guarded by For reactors, runtime must always call |
That's not how I understand the wasip2 spec, my understanding is that |
|
What version of The relevant commit is: bytecodealliance/wasm-tools@108c37d |
|
Once #3165 lands, the |
|
Fixed in #4496. |
|
#4496 merged. Want to try |
|
@rvolosatovs is still necessary? Can you verify against dev branch? |
latest |
Closes #4488
Refs #4482
Turns out
_initializewas not exported bywasip2components and soinit()was never called in reactors. This PR fixes that, by initializing the heap and calling all initializers, just likerun()would normally doNote:
wasm-tools 1.217or later are required forinit()to work in reactors (since_initializeis ignored in earlier versions, see bytecodealliance/wasm-tools#1747)Thanks @alexcrichton for assisting in debugging this in https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime/topic/calling.20.60_initialize.60