On 21/06/2016 02:14, Gavin Lambert wrote:
On 17/06/2016 21:45, Klemens Morgenstern wrote:
But on the other hand from a library design point of view, shouldn't the library have the best smart default in terms of performance and overhead on a given platform ? Instead of having a flag telling : please do it the same but efficiently ? Because on linux vfork is nothing but obsoleted and for a scenario of using execve looks better to me.
Again: obsolete and now removed in the posix-standard and that's what I ought to go with. Please note, that I'm trying to provide two platforms: Posix & Windows. Not Linux & Windows. Thereby I want to provide the most common way for both platforms; and though I really appreciate your scenario, I would not consider it the common way.
Possibly of interest is that according to the notes vfork+exec (and fork+exec, for that matter) was deprecated in favour of posix_spawn. Which appears to be less well documented, but does exist in some environments at least.
Yes it's the code I quoted from the glibc, ( basically Boost.Process is another posix_spawn, brought to another level though) :
The rationale of posix_spawn here is a good addition to what we discuss I think : http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html#ta...
In glibc /sysdeps/posix/spawni.c implementation of posix_spawn:
/* Generate the new process. */ if ((flags & POSIX_SPAWN_USEVFORK) != 0 /* If no major work is done, allow using vfork. Note that we might perform the path searching. But this would be done by a call to execvp(), too, and such a call must be OK according to POSIX. */ || ((flags & (POSIX_SPAWN_SETSIGMASK | POSIX_SPAWN_SETSIGDEF | POSIX_SPAWN_SETSCHEDPARAM | POSIX_SPAWN_SETSCHEDULER | POSIX_SPAWN_SETPGROUP | POSIX_SPAWN_RESETIDS)) == 0 && file_actions == NULL)) new_pid = __vfork (); else new_pid = __fork ();