WASMFS hard-codes stdin, stdout, stderr behavior

[JoeOsborn]

In the JS FS, it's possible to use FS.init(stdin, stdout, stderr) or Module['stdin'] (&c) to customize the standard file handle behaviors. WASMFS does define /dev/stdout (and so on), but hard-codes their behavior to emscripten_out, emscripten_err, and reading a string from a browser prompt (FS_stdin_getChar). stdout and stderr are also always buffered.

Instead, they should use Module['stdin'], Module['stdout'], and Module['stderr'] if defined, or some other mechanism should be used so a caller can wrap a process's input/output.

[sbc100]

BTW, have you ever used the FS.init(stdin, stdout, stderr) method? I was wondering if any programs in the wild actually use that (and hoping to maybe remove it).

[JoeOsborn]

I did use it, because I needed to give commands to my running program over stdin and get results back.

[JoeOsborn]

This problem is actually even more complicated, because the stdin/stdout streams in wasmfs are maintained on a per-thread basis in JS code.

[sbc100]

I did use it, because I needed to give commands to my running program over stdin and get results back.

Would the Module['stdin'] method for your use case?

[sbc100]

This problem is actually even more complicated, because the stdin/stdout streams in wasmfs are maintained on a per-thread basis in JS code.

I imagine the when Module['stdin'] is specified then the wasmfs stdin would instead just be a normal memfs file, not a special stream.

[JoeOsborn]

I think Module['stdin'] might work, but I wasn't aware of it since FS.init was documented on the FS documentation page.

[sbc100]

In your use case how/when did you call FS.init()? e.g. Module.preRun?

[JoeOsborn]

Yes, I defined a stdin function that returned an int and a stdout function that took an int, and used preRun to attach them to the filesystem with FS.init.

[sbc100]

Ah, so in your case they are JS callbacks... that will be trickier to implement. For stdin would providing an array be enough? Or do you need to be able to dynamically generate / stream stdin data?

[JoeOsborn]

The latter. If I could give a callback to be proxied to the main thread, or else get a file handle my JS code could write to while C reads it, those could work. So could a character device implemented in JS via proxy, though this could be slow.

For my specific case I added a new api to my C program for receiving and replying to commands, so this isn’t a blocker for me. But it is a big difference between the JSFS API and the WASMFS one, and I was lucky that I could change the code to work around it.

[kripken]

I agree something here makes sense to add. For WasmFS we should probably start with a C API to override standard streams - that is lower level, and will avoid adding any size to the build for people that don't use the feature. When FORCE_FILESYSTEM is on we include the full JS API, at the cost of code size, so that flag could enable a JS API to use the C API.