From: Jilles Tjoelker <jilles@stack.nl>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
dash@vger.kernel.org, Drake Wilson <drake@begriffli.ch>,
Reuben Thomas <rrt@sc3d.org>
Subject: Re: [PATCH/RFC dash 0/4] Avoid a fork before running last command given to -c
Date: Mon, 18 Apr 2011 00:13:27 +0200 [thread overview]
Message-ID: <20110417221326.GA18973@stack.nl> (raw)
In-Reply-To: <20110415130709.GA3735@gondor.apana.org.au>
On Fri, Apr 15, 2011 at 09:07:09PM +0800, Herbert Xu wrote:
> On Sun, Apr 10, 2011 at 07:18:17AM +0000, Jonathan Nieder wrote:
> > Jilles Tjoelker wrote[0]:
> > > Regarding sh -c optimization, I am in favour of this. Uselessly waiting
> > > 'sh -c' processes annoy me. I made the change for FreeBSD 8.0 sh, which
> > > is very similar to dash. The SVN changeset is r194128.
> > So I grabbed that changeset with
> > svn log -v svn://svn.freebsd.org/base/head/bin/sh -r 194128
> > svn diff -r 194127:194128 svn://svn.freebsd.org/base/head/bin/sh
> > and made it a tiny bit smaller. Here's the result.
> > text data bss dec hex filename
> > 83994 1784 11128 96906 17a8a dash.before-O2
> > 83994 1784 11128 96906 17a8a dash.before-Os
> > 84146 1784 11128 97058 17b22 dash.after-O2
> > 84146 1784 11128 97058 17b22 dash.after-Os
> > On this amd64 the cost is 152 bytes of text. Thoughts?
> I must say that I don't see much value in this feature. Adding
> exec to the invocation is trivial.
It is trivial when writing command lines that are obviously going to be
passed to sh -c, but in practice it is often not done. The optimization
would be useful with system(), popen() and Makefiles; rarely does one
see an "exec" in such contexts. In a Makefile, "exec" can be actively
detrimental since it usually forces the command to be run using the
shell, preventing a direct execve() by make.
In all contexts, "exec" is detrimental if a builtin version of the
executed utility exists. If the utility is a special builtin, prepending
"exec" is very likely to cause the command to stop working, and
otherwise it adds a useless execve().
It was proposed to add text encouraging "exec" prepending to POSIX, but
this was rejected. See http://austingroupbugs.net/view.php?id=236 and
http://thread.gmane.org/gmane.comp.standards.posix.austin.general/1918 .
--
Jilles Tjoelker
prev parent reply other threads:[~2011-04-17 22:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-10 7:18 [PATCH/RFC dash 0/4] Avoid a fork before running last command given to -c Jonathan Nieder
2011-04-10 7:21 ` [PATCH 1/4] [INPUT] Introduce preadateof predicate to check for end of input Jonathan Nieder
2011-04-10 7:22 ` [PATCH 2/4] [EVAL] Make eval flags public Jonathan Nieder
2011-04-10 7:35 ` [PATCH 3/4] [EVAL] Take advantage of EV_EXIT in evalstring Jonathan Nieder
2011-04-10 7:36 ` [PATCH 4/4] [MAIN] Optimize dash -c "command" to avoid a fork Jonathan Nieder
2011-07-07 3:48 ` Herbert Xu
2011-07-07 4:27 ` Jonathan Nieder
2011-07-07 4:57 ` Herbert Xu
2011-07-07 5:56 ` Herbert Xu
2011-07-07 7:48 ` Jonathan Nieder
2011-07-07 8:22 ` Herbert Xu
2011-07-07 8:37 ` Jonathan Nieder
2011-07-07 8:39 ` Herbert Xu
2011-04-10 7:38 ` [PATCH 5/4] [EVAL] Remove unused EV_BACKCMD flag Jonathan Nieder
2011-07-07 3:56 ` Herbert Xu
2011-04-15 13:07 ` [PATCH/RFC dash 0/4] Avoid a fork before running last command given to -c Herbert Xu
2011-04-17 22:13 ` Jilles Tjoelker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110417221326.GA18973@stack.nl \
--to=jilles@stack.nl \
--cc=dash@vger.kernel.org \
--cc=drake@begriffli.ch \
--cc=herbert@gondor.apana.org.au \
--cc=jrnieder@gmail.com \
--cc=rrt@sc3d.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox