-
Notifications
You must be signed in to change notification settings - Fork 118
Fix dangling fd with stdio #287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
1f1c9e2 to
70231f3
Compare
|
@CaptainVincent , this is an alternative fix to #280. |
Mossaka
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
|
Rebased to account for #290. |
|
@Mossaka @jsturtevant PTAL. |
jsturtevant
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, few comments to help my understanding
Signed-off-by: Jorge Prendes <jorge.prendes@gmail.com>
With #260 the stdio
fdare dangling in the parent shim process.Normally redirecting the
stdiowould clear thefds.However, the redirection happens in the
clone3d child process.This means that the parent process maintains a dangling cope of the ´fd´s, keps alive by the shim
Instances.The key changes in this PR are:
Stdionow offers atakemethod.Instanceimpls now usestdio.take()for the last executor, giving up ownership of thefds.The rest of the changes are general fixes:
MuxtexinStdioto anAtomicCell(we need two nested ones to be able to implement ´take´)Stdiowith a generic const.TryFrom<&InstanceConfig<Engine>>forStdio