Skip to content
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

Improve reliability in the face of fork/exec #3

Merged
merged 1 commit into from
Sep 28, 2021

Conversation

jenatali
Copy link
Member

DxgKrnl will return ENOTTY if we have an open fd that wasn't opened by our process. If we have a "valid" (not -1) file descriptor, but we can't use it because of EBADF (already closed, e.g. from O_CLOEXEC) or ENOTTY (not closed, but not from our process), then go ahead and throw away our existing Fd and try to re-initialize it.

Note that other handles won't be able to carry forward. Attempting to use any objects that are still alive from a fork will fail. This just allows the newly-forked process to be able to use graphics even if the forked-from process already was using it.

DxgKrnl will return ENOTTY if we have an open fd that wasn't opened
by our process. If we have a "valid" (not -1) file descriptor, but
we can't use it because of EBADF (already closed, e.g. from O_CLOEXEC)
or ENOTTY (not closed, but not from our process), then go ahead and
throw away our existing Fd and try to re-initialize it.

Note that other handles won't be able to carry forward. Attempting to
use any objects that are still alive from a fork will fail. This just
allows the newly-forked process to be able to use graphics even if
the forked-from process already was using it.
@iourit iourit merged commit bf4f9b6 into microsoft:main Sep 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants