I see how you got to this idea. Unfortunately, I think the "fork + exit without application cleanup will be more efficient than doing application cleanup a longer running process" idea isn't actually true in general practice: fork is expensive due to reference count updates and marking pages as copy-on-write, causing page faults in both parent and child, and then exit results in lots of churn as it walks all child's memory map.
It may be a cheap plan on the application side, but I'm pretty sure the total actual CPU work will be greater. If you want to shift the costs, I guess that fine, but it's not a way to architect an overall system. Philip On Tue, 27 Oct 2020, Luke Small wrote: > Thanks Guenther for the well thought out answer! > > I figured I could take yet another step to sloppiness > which is may actually be more efficient like not calling free() > a bunch of times, because it is handled at > process destruction far more efficiently. > > I know that having a child call exit() instead of _exit() is universally > not the answer unless you want to kill the parent too. > > -Luke > > > On Tue, Oct 27, 2020 at 4:41 PM Philip Guenther <[email protected]> > wrote: > > > > > Yes, there are multiple levels of potential buffering in UNIX and _exit() > > does one level (e.g., socket and serial/terminal buffers) but not another > > (stdio buffers). > > > > The exact handling of stdio buffers and the file-descriptors beneath them > > is subject to minute detail in the POSIX standard, particularly in the > > System Interfaces volume's section "Standard I/O Streams" under "General > > Information". > > > > Are all those people wrong? Well, if they gave "definitely do <blah>" to > > an open-ended question then they've oversimplified to the point of > > misleading. > > > > There are simple cases which can be solved by just using exit() or > > _exit(), but MANY others which require APIs beyond that (fflush(), > > fclose(), etc). A review of the complexity in the standard should make > > that clear. > > > > If you're looking for "always use this hammer, or this wrench", then the > > answer is "nope, you've chosen a problem too complicated for a simple > > answer". Good luck! > > > > > > Philip Guenther > > > > > > On Tue, 27 Oct 2020, Luke Small wrote: > > > from man _exit: > > > > > > All open file descriptors in the calling process are closed. This > > > may entail delays; for example, *waiting for output to drain*. > > A > > > process in this state may not be killed, as it is already dying. > > > > > > -Luke > > > > > > > > > On Tue, Oct 27, 2020 at 4:00 PM Luke Small <[email protected]> wrote: > > > > > > > > > > > > > https://urldefense.com/v3/__https://stackoverflow.com/questions/5422831/what-is-the-difference-between-using-exit-exit-in-a-conventional-linux-fo__;!!ORgEfCBsr282Fw!6tzLqtVZz1nnX08qLekJWOlcNq0D8o9vxitmT0JyKxdTtokGCT6RmlJzY8ekKS9hk6Y$ > > > > > > > > > > Are every single one of these people incorrect? > > > > -Luke > > > > > > > > > > > > On Tue, Oct 27, 2020 at 3:25 PM Philip Guenther < > > [email protected]> > > > > wrote: > > > > > > > >> On Tue, 27 Oct 2020, Luke Small wrote: > > > >> > I have a C program which fork()s and the child process unlink()s > > > >> > /etc/installurl, opens /etc/installurl and writes to it. I > > _exit(0); and > > > >> > I've tested it where the parent returns or exit()s and unless I > > > >> > specifically call fclose() after the fwrite(), the processes will > > close > > > >> > without actually writing to the file. > > > >> > > > > >> > Is this correct functionality? It seems like it ought to not need to > > > >> have > > > >> > an fclose() or even an fflush(). > > > >> > > > >> Yes, it's correct. Call exit(3), not _exit(2) in the child when you > > want > > > >> the functionality of exit(3), such as flushing stdio buffers. > > > >> > > > >> You should follow up with whatever documentation that suggested you > > > >> should > > > >> call _exit(2) in the child, so that it can be corrected. > > > >> > > > >> > > > >> Philip Guenther > > > >> > > > > > > > > > >
