On Tue, Oct 24, 2023 at 03:19:43PM -0400, Greg Wooledge wrote: > On Tue, Oct 24, 2023 at 11:01:55PM +0700, Max Nikulin wrote: > > On 24/10/2023 12:18, tom kronmiller wrote: > > > so I unbuffered stdin and that seemed to make it happy. > > > > It might be performance killer. Even fflush(NULL) before fork() may be > > better.
fflush(NULL) is almost certainly cheaper, and something like it is necessary. The call to fork() does undefined things to stdio state if the relevant files aren't flushed. Correctness matters more than performance, though, so "correct but might be slow" could be a fine answer. The stdio functions and fork() come from different standards, so it's not all that surprising that it's tricky to use both. > > https://stackoverflow.com/questions/50110992/why-does-forking-my-process-cause-the-file-to-be-read-infinitely > > "Why does forking my process cause the file to be read infinitely" > > Ooh, that's got an *excellent* answer. That brings up a subtlety: I've been assuming a Linux-like system, where stdio stuff has an in-process cache, backed by a Unix-style file descriptor. As that page points out, the relevant standards permit quite a bit more than that, much of which is "undefined behavior". That's usually bad news as compiler-writer code for "you're not allowed to do that, and we make no promises whatsoever as to what happens if you try." As this example shows, getting "undefined behavior" can be really quite surprising. > > glibc bug report was closed as invalid > > https://sourceware.org/bugzilla/show_bug.cgi?id=23151 > > > > I am curious why macOS behaves differently. > > It would have been nice if the glibc developer had explained a bit, but > of course we aren't owed any explanations. > > At this point, we can conclude that the bug is in fact in the OP's C > program. The underlying C compiler, C library, and Linux kernel are > all behaving within specs. > > At this point I still don't know *why* glibc rewinds stdin intermittently > on exit(). Apparently Mac OS X doesn't, or at least didn't at the time > the answer was written (2018). I guess there must be some reason for it, > and it's not just randomly pranking people, even if I don't understand > the reason. The standard says that exit() does cleanup like things queued for atexit() and flushes any open files. There's a good reason for that: If you produce some output from a program, you'd be surprised if it just got discarded at the end of the program because it was sitting in an output buffer that hadn't been flushed. If you want the other behavior, there is the similarly named _exit() that doesn't flush output, presumably for cases where there was a fork() for some small task and flushing buffers first wasn't viable. I'd read the documentation carefully, or maybe design to avoid having to read that documnetation. What's probably going on is that under different circumstances the cache of the input is used differently. Maybe the MacOS libc is less prone to read-ahead. Without digging through the code or nominally-opaque FILE* structures, it's hard to say. But I'm pretty sure it's "intermittently the FILE was in a state that didn't cause problems", not "exit() intermittently flushes". Jon Leonard
