[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate
From: |
Paul Eggert |
Subject: |
Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate |
Date: |
Sat, 17 Jun 2023 13:22:05 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 |
On 2023-06-16 09:26, Sergey Bugaev wrote:
Hello,
So how about this?
"Cause operations on the new file descriptor to act as if the named
file is not the process's controlling terminal, even if it is.
@xref{Job Control}.
When @code{O_IGNORE_CTTY} is not set, @code{open} has to perform a
runtime check for the named file being the process's controlling
terminal; setting @code{O_IGNORE_CTTY} allows @code{open} to skip this
check. In case the named file is statically known not to be the
"In case the named file is statically known not to" ->
"If the named file cannot"
@code{O_IGNORE_CTTY} will lead to improved @code{open} performance and
no behavior change. For this reason, it is good practice to always
set @code{O_IGNORE_CTTY} when opening files, unless there is a
possibility that the file being opened could be the process's
controlling terminal."
Replace this with just "@code{O_IGNORE_CTTY} improves performance on the
Hurd." as the rest is redundant.
Although O_IGNORE_CTTY would only matter if the program reopens the tty
explicitly, perhaps as /dev/tty or /dev/stdout, not for the file
descriptors inherited across exec. sudo does this (reopening the
terminal), for example, so if you have a 'sudo xxxx' line in a script
that you run as a background job, it'd steal your input if O_IGNORE_CTTY
behavior was the default.
Fine, so add an O_KEEP_CTTY flag for programs like sudo that want to
play tricks with /dev/tty, and add a feature-test macro like
_DEFAULT_IGNORE_CTTY to let applications choose whether O_IGNORE_CTTY or
O_KEEP_CTTY is the default. If done right this would be an upward
compatible API and ABI change, and would let people fix their apps with
a simple '#define _DEFAULT_IGNORE_CTTY 1' before their other #include
directives, instead of wandering through all their source code looking
for places to add O_IGNORE_CTTY here and there.
Hmm, I see there's a emacs_open[at] wrapper that automatically adds
O_CLOEXEC (and also O_BINARY). So now I've got the same question for
you: does Emacs ever care about the default, !O_IGNORE_CTTY behavior?
Would anything break if I just make emacs_openat always add in
O_IGNORE_CTTY?
Haven't a clue. Why don't you try it and run it for a while? But better
yet, let's change the API as described above, and then try that with Emacs.
- Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate, (continued)
- Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate, Paul Eggert, 2023/06/05
- Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate, Sergey Bugaev, 2023/06/06
- Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate, Paul Eggert, 2023/06/09
- Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate, Sergey Bugaev, 2023/06/09
- Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate, Paul Eggert, 2023/06/09
- Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate, Sergey Bugaev, 2023/06/10
- Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate, Paul Eggert, 2023/06/11
- Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate, Sergey Bugaev, 2023/06/13
- Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate, Paul Eggert, 2023/06/14
- Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate, Sergey Bugaev, 2023/06/16
- Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate,
Paul Eggert <=
- Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate, Samuel Thibault, 2023/06/18
- Re: [PATCH v3 2/2] Use O_IGNORE_CTTY where appropriate, Sergey Bugaev, 2023/06/19
[PATCH v3 1/2] include/fcntl.h: Define O_IGNORE_CTTY, Sergey Bugaev, 2023/06/04