Jesús González (Mar 09 2023 at 15:08): Jesús González (Mar 09 2023 at 15:08):Hi there!
Just dealing with this... simplifying:
Let's say I have a native C program that fopen() a file, writes a few KBs but it doesn't call to fflush() nor fclose() before it exits.
As a rule of thumb, you cannot count on the buffered data being part of the file (especially if the program is externally terminated).
But in some other scenarios, if the program completes its execution without any interruption, the OS may flush the buffered data and close all file descriptors implicitly as part of its housekeeping function. So, if you are lucky, the file may contain the data even if the file was not explicitly closed.
Assuming the above is right, let's say we compile that program with WASI_SDK and run it in Wasmtime.
Wasmtime (process) will own file descriptors on behalf of the C program at the eyes of the OS, right? Once the Wasm program execution is done, what would Wasmtime do with the still-open file descriptors? Will it flush and close them (maybe as part of the Store object deallocation)? Or is there any other optimization mechanism in place that group file descriptors and flushes/closes them altogether?
Jamey Sharp (Mar 09 2023 at 16:13):If you're using C standard file I/O (fopen, fwrite, etc) then libc typically buffers writes in userspace memory. I'm assuming the same is true for wasi-libc, in which case the buffers would be in the wasm instance's linear memory. When the wasm instance exits, nobody else knows where to find those buffers in the linear memory. So I expect that the usual rule applies here: you can't count on the buffered data being written unless you call fflush or fclose.
Jesús González (Mar 09 2023 at 16:49):Thanks @Jamey Sharp . It makes sense.
But I'd add... "unless the Wasm engine performs housekeeping on behalf of the binary", isn't?
Jamey Sharp (Mar 09 2023 at 16:55):The host engine can't perform housekeeping on behalf of the guest binary, because it doesn't know where the guest kept its buffers or its FILE*, or even if the guest did any buffering at all. The guest could have been calling the unbuffered POSIX write function instead of the C library's fwrite function; the host has no way to figure out which.
Jesús González (Mar 23 2023 at 15:48):Oh, I see what you mean.
I was looking at how wasi-common manages file descriptors (through the table) and thought it could help there.
Last updated: Nov 22 2024 at 16:03 UTC