Node.js uvwasi team Meeting 2023-05-10

[mhdawson]

Time

UTC Wed 10-May-2023 18:00 (06:00 PM):

Timezone	Date/Time
US / Pacific	Wed 10-May-2023 11:00 (11:00 AM)
US / Mountain	Wed 10-May-2023 12:00 (12:00 PM)
US / Central	Wed 10-May-2023 13:00 (01:00 PM)
US / Eastern	Wed 10-May-2023 14:00 (02:00 PM)
EU / Western	Wed 10-May-2023 19:00 (07:00 PM)
EU / Central	Wed 10-May-2023 20:00 (08:00 PM)
EU / Eastern	Wed 10-May-2023 21:00 (09:00 PM)
Moscow	Wed 10-May-2023 21:00 (09:00 PM)
Chennai	Wed 10-May-2023 23:30 (11:30 PM)
Hangzhou	Thu 11-May-2023 02:00 (02:00 AM)
Tokyo	Thu 11-May-2023 03:00 (03:00 AM)
Sydney	Thu 11-May-2023 04:00 (04:00 AM)

Or in your local time:

• https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+uvwasi%20team+Meeting+2023-05-10&iso=20230510T1800
• or https://www.wolframalpha.com/input/?i=06PM+UTC%2C+May+10%2C+2023+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1IIENDUO3zBoLys7AV2MhEQqDfA9J9LtJm-6xEZshl9s/edit

Agenda

Extracted from uvwasi-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/node

• WASI preview 1: fd_readdir ignores cookie argument #47193

nodejs/uvwasi

• What's new with uvwasi in 2023 #201
• Implement 4 stubbed out socket methods #200
• Changes to WASI spec in snapshot_preview2 #59

Invited

• uvwasi team: @nodejs/wasi

Observers/Guests

Notes

The agenda comes from issues labelled with uvwasi-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

• link for participants: https://zoom.us/j/91612484369
• For those who just want to watch:
• youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled

[mhdawson]

I'm out at OpenJS World/Open Source summit this week. @cjihrig not sure if you are at the conference as well. If not could you chair/lead the meeting this week?

[cjihrig]

I'm not at the conference but have a separate conflict with the meeting. I suggest we cancel this week and have any necessary discussion on this issue or the relevant issue from the agenda.

[phated]

I'm in favor of cancelling this. I have a lot going on tomorrow

[abrown]

I'm fine with canceling but I did have an update (and request for help!): in order to start checking uvwasi against the wasi-testsuite, I built a libwee8 + uvwasi + libuv binary that runs wasm32-wasi programs using the WASI definitions provided by uvwasi. It's kind of like NodeJS, but without the JS; it's more like d8 (again without JS) but for running Wasm modules with WASI calls. I am currently using a modified version of node_wasi.cc but I need help with:

• making the linking of imports more ergonomic; I want to do something along the lines of SetFunction, but keep on running into C++ template issues
• reducing the binary size; the binary is much too large at the moment, ~270MB, and I was hoping to get some help reducing that.

@cjihrig, are you at all interested in helping me work through some of those issues? I'm on Zulip if you want to discuss asynchronously.

[cjihrig]

I largely stopped following WASI development a while ago, so I apologize if I'm missing something obvious. Why are you building a custom binary? Couldn't you test the WASI behavior of Node.js, wasm3, or one of the other projects that supports embedding uvwasi? Is there some other end goal for this custom binary besides running the WASI test suite? If not, it seems like a lot of work for not much return.

[sbc100]

I'm fine with canceling but I did have an update (and request for help!): in order to start checking uvwasi against the wasi-testsuite, I built a libwee8 + uvwasi + libuv binary that runs wasm32-wasi programs using the WASI definitions provided by uvwasi. It's kind of like NodeJS, but without the JS;

FWIW I got some of the way to imlementing this in wabt. i.e. wasm-interp + uvwasi + libuv.

I think it would be great if we could build something generic that would work with any libwasm.so (i.e. anything that implements the wasm C API such as wasm-interp or libwee8). The generic thing would then work with any wasm runtime.

it's more like d8 (again without JS) but for running Wasm modules with WASI calls. I am currently using a modified version of node_wasi.cc but I need help with:

• making the linking of imports more ergonomic; I want to do something along the lines of SetFunction, but keep on running into C++ template issues
• reducing the binary size; the binary is much too large at the moment, ~270MB, and I was hoping to get some help reducing that.

@cjihrig, are you at all interested in helping me work through some of those issues? I'm on Zulip if you want to discuss asynchronously.

[abrown]

Is there some other end goal for this custom binary besides running the WASI test suite? If not, it seems like a lot of work for not much return.

It wasn't a terrible amount of work (or code) given that I could reuse node_wasi.cc, where most of the work is done. But I would say that I do have another motive: I would like to benchmark V8 in sightglass. To do that I need (1) WASI and (2) a way to convince myself that V8 is completely isolated from things that might impact performance (e.g., the JS side of NodeJS). If I could get this binary working, I am relatively confident I could wire it in with Sightglass... and of course run the wasi-testsuite.

FWIW I got some of the way to imlementing this in wabt. i.e. wasm-interp + uvwasi + libuv.

I mean, if we're just talking about testsuite compliance, though, maybe I should just try that. @sbc100, where should I look to run that?

I think it would be great if we could build something generic that would work with any libwasm.so (i.e. anything that implements the wasm C API such as wasm-interp or libwee8). The generic thing would then work with any wasm runtime.

I agree. As I understand it, #199 is headed towards that and, if implemented, each engine could just link to that to get a WASI implementation.

[sbc100]

king, I am relatively confident I could wire it in with Sightglass... and of course run the wasi-testsuite.

FWIW I got some of the way to imlementing this in wabt. i.e. wasm-interp + uvwasi + libuv.

I mean, if we're just talking about testsuite compliance, though, maybe I should just try that. @sbc100, where should I look to run that?

I think I was a long way from being spec compliant. The code IIRC is here: https://github.com/WebAssembly/wabt/blob/7ff04217d72d5c9528c9f167913c52f083ef1948/src/tools/wasm-interp.cc#L341
And here: https://github.com/WebAssembly/wabt/blob/main/src/interp/interp-wasi.cc. Its been years since I worked on it though so its probably very stale.

[mhdawson]

Meeting passed, believe it was cancelled. Closing.