This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author izbyshev
Recipients gregory.p.smith, izbyshev, koobs, pablogsal, ronaldoussoren, vstinner
Date 2019-01-25.11:17:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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:

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.
Date User Action Args
2019-01-25 11:17:12izbyshevsetrecipients: + izbyshev, gregory.p.smith, ronaldoussoren, vstinner, koobs, pablogsal
2019-01-25 11:17:10izbyshevsetmessageid: <>
2019-01-25 11:17:10izbyshevlinkissue35823 messages
2019-01-25 11:17:10izbyshevcreate