Avoid allocating in pre_exec closure
#104
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The documentation for
pre_execspecifies that allocating in thepre_execclosure is not guaranteed to work.Specifically, this is bad in multi-threaded programs: if the fork occurs while the allocator lock is held by another thread, deadlocks can occur, since there's no one left in the new process to unlock the mutex. I do not believe this is UB, and modern libc offer protections against this issue, but this isn't POSIX-compliant and should preferably be avoided.
zaundoesn't seem to be multi-threaded at a first glance, but I'm filing this anyway as part of going through the list at rust-lang/rust#148971. If it's single-threaded, you don't need to merge this, but I'd play safe.nixprovides a non-allocatingimpl From<Errno> for std::io::Error, which can be used instead. This doesn't allow an additional message to be added, but since error messages aren't transmitted acrosspre_execboundary anyway, this doesn't make visible behavior any worse. On the flip side, this ensures that the correct error code is forwarded to the parent process, instead of the default-EINVAL.