Alexey Izbyshev <izbys...@ispras.ru> added the comment:
> W.r.t. closing all file descriptors > 2: posix_spawn_file_actions_addclose > can do this when using posix_spawn. That would have a performance cost, you'd > basically have to resort to closing all possible file descriptors and cannot > use the smarter logic used in _posixsubprocess. This is costly to the point of people reporting bugs: bpo-35757. If that really causes 0.1s delay like the reporter said, it would defeat the purpose of using posix_spawn() in the first place. > However, the smarter closing code in _posixsubprocess is not safe w.r.t. > vfork according to the comment above _close_open_fds_maybe_unsafe: that > function uses some functions that aren't async-safe and one of those calls > malloc. No, it's not so on Linux: https://github.com/python/cpython/blob/62c35a8a8ff5854ed470b1c16a7a14f3bb80368c/Modules/_posixsubprocess.c#L314 Moreover, as I already argued in msg332235, using malloc() after vfork() should be *safer* than after fork() for a simple reason: all memory-based locks will still work as though the child is merely a thread in the parent process. This is true even for things like futex(FUTEX_WAKE_PRIVATE), despite that this operation is mistakenly documented as "process-private" in man pages. It's actually more like "private to tasks sharing the same address space". This is in contrast with fork(): if it's called while another thread is holding some mutex in malloc(), nobody would unlock it in the child unless the C library has precautions against that. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35823> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
