[Top][All Lists]

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

Re: forked before bash subshell

From: Bob Proulx
Subject: Re: forked before bash subshell
Date: Thu, 13 Oct 2016 21:05:29 -0600
User-agent: NeoMutt/20160916 (1.7.0)

XiaoBing Jiang wrote:
> Greg Wooledge wrote:
> > If you want to ENSURE that the child shell process is replaced by the
> > external sleep 20, use an explicit exec.
> yes, I want to know why bash not optimize this. or any strategy ?

Because it wouldn't save anything significant.  Since the parent shell
is bash the extra bash in memory is already in memory.  A forked
process uses almost the same OS memory as the original.  The OS will
share the code pages between the two processes at the OS memory page
level.  Data pages will split when they are individually modified.
Even if you use 'exec' to replace the forked and backgrounded copy
another one is still in memory as the script runs.  Only unique data
pages will go through the copy-on-write process as the two bash
processes diverge.  Therefore even if you *think* you are saving
something by optimizing it out the actual savings is insignificantly

Plus this is really only a problem if the main part of the script
exits leaving the forked subshell running in the background.  However
that is not a good thing to do.  If you want to leave the process
running that is a daemon process.  Launching a daemon process needs
more setup than this to avoid other problems.  Since leaving processes
behind like that is a bad thing to do it again doesn't make much sense
to try to optimize the doing of it.

It is possible to contrive some examples where it makes sense to do
this optimization.  But mostly they are very unusual cases.  Not
typical cases.


reply via email to

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