Move stdout and stderr line buffering responsibility to shell.html

[juj]

Something I've been thinking of doing for quite a while - currently we expect that stdout and stderr streams are line buffered (e.g. like console.log() is) by requirement, and for example on fflush() we can only flush full lines. However different environments have support for different granularities. For example:

• we can flush individual characters when printing to a text box on a web page, so that does not need to depend on line buffering
• when one is using window.dump() to debug, then we would be able to support char buffering
• when one is using emrun debug harness, then we can support char buffering
• when one is using a shell like node.js or SpiderMonkey, then we can also do char buffering

It would make sense to remove the abstractions for line buffering and rebuild them in the default shell.html file instead. That would allow a clean way to fix #2770.

The only drawback is for people who use a custom shell file, if behavior changed on them to suddenly buffer chars instead of lines, then they would see incorrectly split console.log() prints. Therefore the feature would perhaps need to be an option that one opts in to.

Any objections?

[kripken]

How about something like this: we add Module.printChar and Module.printCharErr, that receive single characters, and where we can, we implement them as printing out those single characters (like to an html textbox)? Then the few places that do want to print individual chars (like the syscall for printing) would call that. Everything else can continue to call print normally, and would still work.

Then if people use their own shell file, if they implement printChar we would call it, if not then we have a standard buffering impl that calls print when a full line is buffered, etc.

(Maybe with a better name than printChar.)

[juj]

That sounds workable (with the change that the function should not be restricted to receiving only single characters, but should work with arbitrary length strings, with \n in them)

How about Module.writeStdout and Module.writeStderr?

[kripken]

So print/printErr would be full lines, while write/writeErr receives characters not ending in a newline, and can print them when possible? I wish we had a better name here than print vs write, but maybe write is "low-level" and it's ok.

[rajsite]

I'm also interested in having a lower-level function to plug into.
We print some binary data to stdout and with NO_FILESYSTEM=1 and overriding the current Module.print and Module.printErr I can't distinguish between null and newline: https://github.com/kripken/emscripten/blob/52ff847187ee30fba48d611e64b5d10e2498fe0f/src/library_syscall.js#L162

I also don't need the UTF8ArrayToString behavior so having Module.write / Module.writeErr or the ability overwrite SYSCALLS.printChar seems useful.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

[vadimkantorov]

@kripken @sbc100 Could you please reopen this issue? I stumbled on this when porting clear program which does not print end line: #2770 (comment) How do I force stream flush from JavaScript? I'm calling _main function manually, so libc cleanup does not apply in my case. Having more flexibility on buffering / stream flushing is very useful.

[sbc100]

I think you can just call fflush(). If that isn't enough you can also call fsync(). Bypassing the buffering that musl is don't is probably not something we want to do.

[vadimkantorov]

I'll call fflush, but I think it'd be good to have it bound by default by Emscripten