-
Notifications
You must be signed in to change notification settings - Fork 913
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(wasip2): export _initialize
#4490
Conversation
ran same scenario as in #4482 Before
With this PR
🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
_initialize
was not exported bywasip2
components 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.217
or later are required forinit()
to work in reactors (since_initialize
is 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