34 ms·
fork() is not per se "dangerous" in such context. You just have to be careful enough and only use asynchronous-signal-safe fonctions, as you would do in a signa
by xroche 10y ago
fork() is not per se "dangerous" in such context. You just have to be careful enough and only use asynchronous-signal-safe fonctions, as you would do in a signal handler (see https://www.securecoding.cert.org/confluence/display/c/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers https://www.securecoding.cert.org/confluence/display/c/SIG30...)
Typically calls such as malloc(), printf() etc. are strictly forbidden in the child after a fork().
- ej_campbell 10y agoOnly if your app is multi-threaded. Unfortunately, many apps are multi-threaded "under the covers" due to libraries that spawn threads, so you need to be careful. This post does the best job explaining the issue: http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them http://www.linuxprogrammingblog.com/threads-and-fork-think-t...
- evanj 10y agoThis is possible, but I find these restrictions to be hard to follow. As soon as you need to call a function, you now need to audit that function to determine that it only calls other async signal safe functions. When you come back to the code to fix a bug six months later, you need to remember these restrictions. Do this when you must, but it is easy to screw up.