Hi, tom kronmiller wrote: > I ended up using setvbuf(stdin, NULL, _IONBF, 0) in the parent process and > that seems to have fixed the actual program I was having trouble with.
stdin ? Not setvbuf(stdout, NULL, _IONBF, 0) ? That would be one of the weirder remedies and explanations which can be found in the web. The one pointed to by Max Nikulin: > https://stackoverflow.com/questions/2530663/printf-anomaly-after-fork > fork clones stdout buffer and child exit flushes its content. would halfways explain what i see with unwritten data in the stdout buffer. But i am not sure that this is what man 2 fork means by: * The child inherits copies of the parent's set of open file descripâ tors. Each file descriptor in the child refers to the same open file description (see open(2)) as the corresponding file descriptor in the parent. This means that the two descriptors share open file status flags, current file offset, and signal-driven I/O attributes (see the description of F_SETOWN and F_SETSIG in fcntl(2)). Further i wonder why i never had such problems with fork() during the last decades. Will have to inspect my own programs what exactly they do with stdout around forking. Jon Leonard wrote: > More specifically, fork() does not play nicely with stdio buffering. That's a good summary of the internet's consensus on that topic. > Depending on the task, it may be easier to use the underlying > read() and write() calls. I am curious whether write() to file descriptor 1 would show different behavior than printf(). Maybe tomorrow ... Have a nice day :) Thomas
