Re: [dev] ii: how to process out in a pipeline and still page with less

From: Markus Wichmann <nullplan_AT_gmx.net>
Date: Mon, 30 May 2022 06:26:57 +0200

On Sun, May 29, 2022 at 10:20:05PM +0000, Rodrigo Martins wrote:
> It was thus said that the Great Markus Wichmann once stated:
> > And you fundamentally cannot change anything about the userspace of another program, at least not in UNIX.
>
> When I open file descriptors and exec(3) the new program inherits
> those. Is that not chaning the userspace of another process?
>

Program, not process. And no, it is changing the kernelspace of another
program. For userspace, file descriptors are just numbers. They attain
meaning only from the kernel interface.

> It was thus said that the Great Markus Wichmann once stated:
> > Having one special-case program is better than changing all the general ones, right?
>
> Sure is. Too bad the stdbuf(1) uses such a fragile mechanism.
>

Well, I cannot think of anything else they could have done.
Fundamentally, setting environment variables and hoping the target
program will interpret them correctly is about the extent of what an
external filter is capable of, here.

> What if instead of changing every program we changed the standard
> library? We could make stdio line buffered by setting an environment
> variable.
>

The problem you run into here is that there is more than one standard
library, and indeed it is even thinkable that some programming language
may shirk libc entirely. Golang has been trying their damndest at that
for a long time, just didn't go all the way and still wanted to use
libpthread. Haskell/GHC would be another candidate, as would be Pascal.

The only way to roll out a change that would affect all programs at the
same time would be a kernel update, but as discussed, this is a
userspace problem to solve.

Plus, the environment variable idea breaks with programs with elevated
privilege, but that is probably a good thing here.

Ciao,
Markus
Received on Mon May 30 2022 - 06:26:57 CEST

This archive was generated by hypermail 2.3.0 : Mon May 30 2022 - 06:36:08 CEST