Re: bash uses tmp files for inter-process communication instead of pipes?

[Linda Walsh]

Greg Wooledge wrote:
> OK, then use a function to give you an escapable block:
>
> declare -A ...
> create_maps() {
>     cd "$sysnet" || return
>     for ifname in ...; do
>         hwaddr=$(<"$ifname"/address)
>         act_hw2if[$hwaddr]="$ifname"
>         act_hw2if[$ifname]="$hwaddr"
>     done
> }
> create_maps
>
> > Either way, they code as you have suggested won't work
> > without overcoming another set of side effects.
>
> There are ways to NOT use subshells.  I have given you two of those
> ways now.
----

        I appreciate the options, but the option I want is the parent staying
"put", and only sending children out to change dir's.  Say some new
version of init wants to isolate init processes by putting them in their
own dir and then deleting the dir.  As long as they don't cd out of the
dir, they are fine, but if they do, they can't get back to it.

        Why can't I spawn a child that cd's into a dir and reports back what
it finds in the dir?  I do this in perl or C w/no problem.

I have an iomonitor program, that monitors multiple data inputs.  For
each, I spawn a child that sits in that directory, holding the FD open
and rewinding it for updated status.  There's no constant
opening/reopening of files -- no walking paths.  Each time you open
a path, the kernel has to walk the path -- if cached, happens very
quickly -- but still work as it also has to check access on each
traversal (it can change).  If your data-gathering routines sit where
the data is and don't move, there is no waisted I/O or CPU accessing the
data and the parent gets updates via pipes.

There is no fundamental reason why, say, process substitution needs to
use /dev/fd or /proc/anything -- and couldn't operate exactly like piped
processes do now.  On my first implementation of multiple IPC programs,
I've used semaphores, message queues, named pipes, and shared memory.
With the exception of using shared memory for mutiple megabytes of
memory for each of several children, pipes provided equal or better
performance.

It was certainly fun to try the various methods and compare them, but
having an implementation that only depends on the LCD (pipes in this
case), would make the code more portable and faster.  For HEREDOC's
there is no reason why chet couldn't use his own STDIO lib for the needs
of bash that keep everything in memory or spill on extra large sizes.

Design choice doesn't have to become feature constraint -- or if it
does, then it's time to think about a different design choice.  Then all
of those features that currently use linux-only or linux-like extensions
like proc and /dev/fd can be ported to platforms that don't support such
a wide feature set.