On Friday, 19 February 2021 at 13:42:46 UTC, Steven Schveighoffer wrote:

[...]

> ignoring SIGPIPE is a process-wide thing, and so it's not appropriate for Phobos to make that decision for you. But it's trivial to ignore it.

Sure.

> I've never been a fan of SIGPIPE. If you look around on the Internet, you'll find that most people agree that the reasoning for SIGPIPE is to fix poor programming (i.e. ignoring of error codes).

As application programmer I don't want to check any error codes.
Thankfully I don't have to in D. There is a nice off-topic example
from the linux kernel [1] what happens when people do not check
return values [1].

> But it doesn't give you any good way to handle it. A SIGPIPE can be due to any pipe being written, it doesn't tell you which one. In order to know which one caused it, well, you have to look at the error code of the call!

Fortunately the D runtime /does/ take care and it throws---if the signal
is ignored beforehand. I filed issue 21649.

[1] <https://lore.kernel.org/patchwork/patch/260181/>
    move RLIMIT_NPROC check from set_user() to do_execve_common()

On Friday, 19 February 2021 at 15:39:25 UTC, kdevel wrote:
> On Friday, 19 February 2021 at 13:42:46 UTC, Steven Schveighoffer wrote:
>
> [...]
>
>> [...]
>
> Sure.
>
>> [...]
>
> As application programmer I don't want to check any error codes.
> Thankfully I don't have to in D. There is a nice off-topic example
> from the linux kernel [1] what happens when people do not check
> return values [1].
>
>> [...]
>
> Fortunately the D runtime /does/ take care and it throws---if the signal
> is ignored beforehand. I filed issue 21649.
>
> [1] <https://lore.kernel.org/patchwork/patch/260181/>
>     move RLIMIT_NPROC check from set_user() to do_execve_common()

Perhaps a bit late, but this is how I deal with pipes and spawnShell.
Read one byte at a time from stdout and stderr:

https://github.com/DannyArends/DaNode/blob/master/danode/process.d

Danny

On Monday, 22 February 2021 at 13:23:40 UTC, Danny Arends wrote:

> https://github.com/DannyArends/DaNode/blob/master/danode/process.d
>
> Danny

This example shows how easy it is to implement a non-blocking stream. Phobos knows this for sockets but not for pipes?

On Monday, 22 February 2021 at 13:23:40 UTC, Danny Arends wrote:
> On Friday, 19 February 2021 at 15:39:25 UTC, kdevel wrote:
>> [...]
>
> Perhaps a bit late, but this is how I deal with pipes and spawnShell.
> Read one byte at a time from stdout and stderr:
>
> https://github.com/DannyArends/DaNode/blob/master/danode/process.d
>
> Danny

Interesting, do you have any benchmarks for DaNode?

On Monday, 22 February 2021 at 13:23:40 UTC, Danny Arends wrote:
> On Friday, 19 February 2021 at 15:39:25 UTC, kdevel wrote:

[...]

>> Fortunately the D runtime /does/ take care and it throws---if the signal
>> is ignored beforehand. I filed issue 21649.

[...]

> Perhaps a bit late,

It's never too late.™ :-)

> but this is how I deal with pipes and spawnShell.
> Read one byte at a time from stdout and stderr:
>
> https://github.com/DannyArends/DaNode/blob/master/danode/process.d

Is this immune to SIGPIPE and is this design able to serve infinite
streams? BTW: Why does run use spawnShell and not spawnProcess (would
save one File object).

If the design is not intended to serve infinite streams I would
suggest to open two temporary files "out" and "err", delete them,
and let the child process write stdout/stderr into those files.
IFAICS this avoid threads, sleep, pipe and reading with fgetc.