bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pierre Gaston
Subject: Re: bash uses tmp files for inter-process communication instead of pipes?
Date: Tue, 7 Oct 2014 20:56:49 +0300

On Tue, Oct 7, 2014 at 8:45 PM, Linda Walsh <bash@tlinx.org> wrote:

>
>
> 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.
>

That's where you are wrong, there is no reason for *your* use case, but the
basic idea behind process substitution is to be able to use a pipe in a
place where you normally need a file name.


reply via email to

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