2 ms·
As the author of a gist that trashes on fork(), I do nonetheless use it, usually early in daemons' lives: - to daemonize - to fork multiple worker processe
by cryptonector 4y ago
As the author of a gist that trashes on fork(), I do nonetheless use it, usually early in daemons' lives:
- to daemonize
- to fork multiple worker processes
And maybe POSIX-ish shells should use fork() for subshells, naturally.
But I think that's about it for good uses of fork().
For all process spawning uses of fork() I strongly recommend vfork() or posix_spawn() instead.
- masklinn 4y agoIsn't the first use-case a pretty debatable / bad one? By daemonizing internally, you make service management and supervision of the program much more difficult, and if you include a non-daemonizing mode for debugging you now have two different runmodes with a pretty significant semantics difference, only one of which is easily inspectable.
- cryptonector 4y agoDaemonizing is a thing of the past with modern restarter frameworks, like SMF, systemd, supervisord, etc. But daemonizing was always an option, not a requirement, and as an option, it's safe enough to provide it for those who don't use a restarter.
- gunapologist99 4y agoYour program probably knows how (if it wished) to manage its own resources far better than an external program ever could.
- masklinn 4y agoSaid no sysadmin ever.
- lanstin 4y agoI love this sysadmin comment and the GP dev comment. The key is to get the sysadmin team putting requirements to the code, whether the restarting ends up in process or as a nice small unix separate tool that just does restarts well, is an outcome of a process.