On 14 August 2012 17:22, Niklas Larsson <metanik...@gmail.com> wrote:
> 2012/8/14 Alexander Kjeldaas <alexander.kjeld...@gmail.com>: > > > > > > On 13 August 2012 23:49, Richard O'Keefe <o...@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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe