* Adam Borowski: > On Sun, Nov 11, 2018 at 12:46:35PM +0100, Florian Weimer wrote: >> A lot of multi-threaded applications assume that most high-level >> functionality remains usable even after fork in a multi-threaded >> process. > > How would this be even possible? Currently fork kills all threads > (save for the caller). glibc's fork acquires several locks around fork. Other mallocs install fork handlers, too. > Glibc's manpage also warns: > > # After a fork() in a multithreaded program, the child can safely call only > # async-signal-safe functions (see signal-safety(7)) until such time as it > # calls execve(2). > > Which makes sense as its malloc uses a mutex, and you can't take a breath > without a library call using malloc somewhere (or in C++, the language > itself). Right, but applications require a working malloc after fork, unfortunately. opendir is often used to enumerate file descriptors which need closing, for example. Thanks, Florian
