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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.