Skip to content

Conversation

@Zheaoli
Copy link
Contributor

@Zheaoli Zheaoli commented Sep 29, 2025

Zheaoli and others added 2 commits September 29, 2025 17:42
Signed-off-by: Manjusaka <[email protected]>
Signed-off-by: Manjusaka <[email protected]>
@Zheaoli
Copy link
Contributor Author

Zheaoli commented Oct 8, 2025

@vstinner Thanks for your time. PTAL when you get time

Signed-off-by: Manjusaka <[email protected]>
Signed-off-by: Manjusaka <[email protected]>
Signed-off-by: Manjusaka <[email protected]>
Signed-off-by: Manjusaka <[email protected]>
@Zheaoli
Copy link
Contributor Author

Zheaoli commented Oct 9, 2025

@vstinner Done

Copy link
Member

@picnixz picnixz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

os.* functions are meant to mimic libc ones. As such, I'm not sure we should forcibly change inheritance (or does forkpty actually sets O_CLOEXEC as well?). Instead I would suggest one of the two:

  • add an additional parameter to forkpty to allow setting O_CLOEXEC at the same time.
  • add a separate function (I don't have a name for it) that does it.

if (pid == -1) {
return posix_error();
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you need this change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this change, it helps readability :-)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering the function is already very compact, I don't think it helps much. But I wouldn't mind having more blank lines in the entire function to really help readability (the return is usually sufficiently clear IMO; I'm more worried about the all those ifs before actually calling forkpty)

@vstinner
Copy link
Member

vstinner commented Oct 9, 2025

os.* functions are meant to mimic libc ones. As such, I'm not sure we should forcibly change inheritance

There is PEP 446 "Make newly created file descriptors non-inheritable" which requires Python to create new file descriptors as non-inheritable.

I see this change as a bugfix, but I prefer to not backport it to avoid bad surprises to users.

Zheaoli and others added 5 commits October 9, 2025 22:36
Co-authored-by: Bénédikt Tran <[email protected]>
Co-authored-by: Bénédikt Tran <[email protected]>
Signed-off-by: Manjusaka <[email protected]>
Signed-off-by: Manjusaka <[email protected]>
Copy link
Member

@vstinner vstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for the update! It now looks good to me with PyErr_FormatUnraisable().

@vstinner vstinner merged commit 7cafd76 into python:main Oct 10, 2025
81 of 83 checks passed
@vstinner
Copy link
Member

Merged, thank you.

@Zheaoli
Copy link
Contributor Author

Zheaoli commented Oct 11, 2025

Merged, thank you.

@vstinner @picnixz thanks for your time!

@Zheaoli Zheaoli deleted the manjusaka/fix-139184 branch October 11, 2025 13:43
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.

4 participants