-
Notifications
You must be signed in to change notification settings - Fork 97
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
Fix dangling fd with stdio #287
Conversation
1f1c9e2
to
70231f3
Compare
@CaptainVincent , this is an alternative fix to #280. |
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. |
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 <[email protected]>
With #260 the stdio
fd
are dangling in the parent shim process.Normally redirecting the
stdio
would clear thefd
s.However, the redirection happens in the
clone3
d child process.This means that the parent process maintains a dangling cope of the ´fd´s, keps alive by the shim
Instance
s.The key changes in this PR are:
Stdio
now offers atake
method.Instance
impls now usestdio.take()
for the last executor, giving up ownership of thefd
s.The rest of the changes are general fixes:
Muxtex
inStdio
to anAtomicCell
(we need two nested ones to be able to implement ´take´)Stdio
with a generic const.TryFrom<&InstanceConfig<Engine>>
forStdio