[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bash-bug
Subject:    omit fork before last exec
From:       John Reiser <jreiser () bitwagon ! com>
Date:       2009-08-04 2:05:34
Message-ID: 4A77976E.9020703 () bitwagon ! com
[Download RAW message or body]

Hi,

Would it be possible for bash to detect just-in-time the last subprocess
that it will execute, and then do only an 'execve' instead of a fork+execve?
This might save a lot of operating system overhead for process creation:
perhaps upto 10% over the course of a day, especially for most uses of 'make'.

It seems to me that this could work if there are no active traps
and if the shell's input can be re-positioned without penalty.
An active trap might get triggered by the supposed last subprocess;
then interpreting the body of the trap could invalidate the "last subprocess"
property.  If the shell's input cannot be repositioned (is not a regular
file or "-c" command line string; is a pipe, socket, fifo, character device,
etc.) then lookahead on the shell's input is problematic.  Lookahead
is necessary to determine the "last subprocess" property.  However, the
lookahead must be undone before exec so that semantics remain the same
for the case when the shell and a subprocess share the input stream.
Piping input into a shell often relies on alternating consumption of
the piped input by the shell and one or more subprocesses that have
un-redirected stdin.

Comments?

-- 



[prev in list] [next in list] [prev in thread] [next in thread]