On 14 August 2012 17:22, Niklas Larsson <metaniklas@gmail.com> wrote:
2012/8/14 Alexander Kjeldaas <alexander.kjeldaas@gmail.com>:
>
>
> On 13 August 2012 23:49, Richard O'Keefe <ok@cs.otago.ac.nz> wrote:
>>
>>
>> On 13/08/2012, at 11:26 PM, Alexander Kjeldaas wrote:
>>
>> >
>> > This isn't that hard - a pipe shouldn't be needed anymore.  Just require
>> > a post-2003 glibc.
>> >
>> > fexecve is a system call in most BSDs.  It is also implemented in glibc
>> > using a /proc hack.
>>
>> fexecve is now in the Single Unix Specification, based on
>> POSIX as of 2008, I believe.  However,
>> http://www.gnu.org/software/gnulib/manual/html_node/fexecve.html
>> says
>> Portability problems not fixed by Gnulib:
>>   *  This function is missing on many non-glibc platforms: MacOS X 10.5,
>> FreeBSD 6.0,
>>      NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX 6.5,
>> OSF/1 5.1,
>>      Solaris 11 2010-11, Cygwin 1.5.x, mingw, MSVC 9, Interix 3.5, BeOS.
>>
>> That warning doesn't seem to be fully up to date.  I'm using MacOS X
>> 10.6.8
>> and fexecve() isn't in the manuals or in <unistd.h>.
>>
>
> FreeBSD 8.0 is covered.
> OpenBSD not covered
> OS X not covered
> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/execve.2.html
> Solaris probably not covered.
>
> So support is pretty good, I'd say. For non-modern systems, checking the
> existence of the file first is possible.  The race isn't important, and one
> can always upgrade to a modern operating system.
>

The check would be unreliable, the file's existence doesn't imply that
it's executable.

See access(2)
 
Furthermore it would add unnecessary overhead,
createProcess can be run thousands of times in a program and should be
lean and mean.


Just to keep the bikeshedding doing, I'm going to state as a fact that running performance sensitive *server* workload on any unix other than Linux is purely of theoretical interest.  No sane person would do it.  Therefore, from a performance overhead, Linux performance is the only important performance measure.

But even given the above, the overhead we're talking about is minuscule.  A program like '/bin/echo -n '''  which does exactly *nothing*, requires 35(!) system calls to do its job :-).
A more complex program like 'id' requires 250 system calls!

Also, to see just how minuscule this is, the dynamic linker, ld-linux.so does a few extra access(2) system calls *to the same file*, /etc/ld.so.hwcaps, on startup of every dynamically linked executable.  2 in the 'echo' case, and 8 in the 'id' case above.  Even the glibc folks haven't bothered to optimize those syscalls away.

Alexander