[Top][All Lists]

[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:

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]