Re: [Valgrind-users] New --track-fds=new option expected behaviour

[John R. <jr...@bi...>]

> I'm trying to add a new option for the --track-fds.
> https://bugs.kde.org/show_bug.cgi?id=493433 

It seems to me that --track-fds=OPTION also should be aware
of the use of multiple fds for parallel processing at shell level.
User-level shell code creates a fan-out of multiple fds,
and instantiates one process per fd, with stdin re-directed
from the corresponding fd of the fan.
Stdout of the nest of processes is fanned-in
to a common fd by redirecting stdout from each process.
Then a shell loop directs its stdout into the proper fd
for each process.  Thus the supervising shell script
chooses which process in the pool gets which input, and
each input is processed by the selected process, running
in parallel with other pool processes on other inputs.

The important point is that --track-fds in any pool process
should ignore completely the other fds in the fan-out.
Of course each process can snoop and interfere
with those fds (data is flowing through them, too)
but proper coding avoids that.  In particular, each
pool process should NOT use close_range() which might
include a fanned-out fd for a different process.
[See also the manpage for 'bash' shell, section REDIRECTION:
    Each redirection that may be preceded by a file descriptor
    number may instead be preceded by a word of the form {varname}.
    In this case, for each redirection operator except >&- and <&-,
    the shell will allocate a file descriptor greater than or equal
    to 10 and assign it to varname. ]