RE: libiberty/pex-unix vfork abuse?

RE: libiberty/pex-unix vfork abuse?

[J.C. Pizarro]

On 2007/12/07, "Dave Korn" <dave.korn@artimi.com> wrote:
> > On the other hand, the setting of environ is very dubious and is
> > likely to break on real systems.  The code should be changed to call
> > execve instead.  Unfortunately there is no standard execvpe function.
> > Fortunately gcc never uses the variant which sets environ.  Offhand
> > I'm not sure what does.
>
>   Perhaps we could work around this case by setting environ in the parent
> before the vfork call and restoring it afterward, but we'd need kind of
> serialisation there, and I don't know how to do a critical section using
> pthreads/posix.

You can do a critical section mainly between processes using system calls of
IPC synchronization like filelocks, RPCs, shared memory with mmap and
mutexes/semaphores, messages passing through pipes as tunnels, MPI, etc.

Now well, a critical section between multithreaded processes are complicated.

   J.C.Pizarro

RE: libiberty/pex-unix vfork abuse?

[Dave Korn]

On 07 December 2007 17:24, J.C. Pizarro wrote:

> You can do a critical section mainly between processes 

  Thanks for your well-meaning attempt to help, but you don't understand what
we're talking about, and sending a generic list of synchronisation techniques
without regard to their relevance or applicability in this situation doesn't
actually tell either me or Ian anything we didn't already know nor advance the
discussion any.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: libiberty/pex-unix vfork abuse?

[Joe Buck]

On Fri, Dec 07, 2007 at 05:41:50PM -0000, Dave Korn wrote:
> On 07 December 2007 17:24, J.C. Pizarro wrote:
> 
> > You can do a critical section mainly between processes 
> 
>   Thanks for your well-meaning attempt to help, but you don't understand what
> we're talking about, and sending a generic list of synchronisation techniques
> without regard to their relevance or applicability in this situation doesn't
> actually tell either me or Ian anything we didn't already know nor advance the
> discussion any.

And this is hardly an isolated case.  J.C., please stop responding to
every issue with a grab-bag of buzzwords and generic solutions.  As
Dave says, you aren't telling people anything they didn't know.

If you actually experiment with a specific idea and have data, by all
means submit that.  But random suggestions based on something you read in
school are useless, and many developers on this list already took those
classes and read those papers.

Re: libiberty/pex-unix vfork abuse?

[J.C. Pizarro]

2007/12/7, Joe Buck <Joe.Buck@synopsys.com> wrote:
> On Fri, Dec 07, 2007 at 05:41:50PM -0000, Dave Korn wrote:
> > On 07 December 2007 17:24, J.C. Pizarro wrote:
> >
> > > You can do a critical section mainly between processes
> >
> >   Thanks for your well-meaning attempt to help, but you don't understand what
> > we're talking about, and sending a generic list of synchronisation techniques
> > without regard to their relevance or applicability in this situation doesn't
> > actually tell either me or Ian anything we didn't already know nor advance the
> > discussion any.
>
> And this is hardly an isolated case.  J.C., please stop responding to
> every issue with a grab-bag of buzzwords and generic solutions.  As
> Dave says, you aren't telling people anything they didn't know.
>
> If you actually experiment with a specific idea and have data, by all
> means submit that.  But random suggestions based on something you read in
> school are useless, and many developers on this list already took those
> classes and read those papers.

> But random suggestions based on something you read in school are useless

You're wrong. My suggestions are not based from school and are not useless.
My suggestions are based from university, books, papers and internet, and
i did put those by a same reason, my freedom.

Do you permit me a question for you?

   "Are important the suggestions?"

   J.C.Pizarro

Re: libiberty/pex-unix vfork abuse?

[Andrew Haley]

J.C. Pizarro writes:

 > You're wrong. My suggestions are not based from school and are not useless.
 > My suggestions are based from university, books, papers and internet, and
 > i did put those by a same reason, my freedom.

You have the freedom to make useless postings to this list, just as we
have freedom to ask you to stop.  Please stop.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

RE: libiberty/pex-unix vfork abuse?

[Dave Korn]

On 07 December 2007 18:09, J.C. Pizarro wrote:

> You're wrong. My suggestions are not based from school and are not useless.

  Now /you're/ wrong: your suggestions *are* useless.  You suggested using
inter-process communications to try and resolve a potential data-access race
condition between multiple threads within the *same* process.  This can NOT be
done by any of "filelocks, RPCs, shared memory with mmap and
mutexes/semaphores, messages passing through pipes as tunnels, MPI".

 - A filelock cannot be used to prevent a second thread within the same
process from reading from or writing to the environ[] array (or any other
variable) or calling setenv/getenv while a first thread temporarily swaps the
value in it.

 - A remote procedure call cannot stop a second thread in the same process
from reading the environ[] array (or any other ... (etc).

 - An mmap'd shared memory block cannot stop a second thread  ... (etc).

 - Passing a message through a pipe cannot stop a second thread ... (etc).

 - A mutex/semaphore *could* do this, but only if every call to getenv/setenv
and every direct access to the environ array were *also* wrapped in mutex lock
calls.  This is not something you can work around in a library implementation
of pexecute, it would require every author of every program that uses
libiberty to modify their entire code.

  The fact that you have suggested all those useless suggestions proves that
you have not understood what we are discussing, which was how to temporarily
alter the value of a global variable in one thread of a program without any
other thread seeing the altered value, when we do not control the other
threads because we are just a library function, not the application itself.
The generic solution for this problem, which I mentioned in my original post,
is a "critical section", which is a stretch of code that locks out the
scheduler from scheduling any other threads of the process to run during the
period the lock is held.

> Do you permit me a question for you?
> 
>    "Are important the suggestions?"

  Their importance is proportional to the product of their relevance
multiplied by their feasibility.  Your suggestions above were all irrelevant,
except for the unfeasible one.  0*(anything) == (anything)*0 == 0*0 == 0.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: libiberty/pex-unix vfork abuse?

[Diego Novillo]

On 12/7/07 1:09 PM, J.C. Pizarro wrote:

> Do you permit me a question for you?
> 
>    "Are important the suggestions?"
> 
>    J.C.Pizarro

JC,

The problem that many of us have with your responses is that they are 
almost always content-free.  You do not seem to grasp the basic 
principles of the issues that you write about.  Your responses are 
purely an amalgamation of very basic terms that you seem to have gotten 
from books/papers.

We *all* know those things.  We generally take that for granted.  So, 
when you offer only that information, you are not contributing anything 
to the discussion.  You are just adding noise.

The problem is that over time, people stop listening to you and then 
when you eventually do have an actual contribution, nobody will listen 
to it, because people will already be too tired of arguing with you.

Just a suggestion.  Maybe you *do* have something useful to contribute, 
it's just hard to see what it might be.


Diego.

Re: libiberty/pex-unix vfork abuse?

[J.C. Pizarro]

On 2007/12/7, Dave Korn <dave.korn@artimi.com> wrote:
> On 07 December 2007 18:09, J.C. Pizarro wrote:
>
> > You're wrong. My suggestions are not based from school and are not useless.
>
>   Now /you're/ wrong: your suggestions *are* useless.  You suggested using
> inter-process communications to try and resolve a potential data-access race
> condition between multiple threads within the *same* process.  This can NOT be
> done by any of "filelocks, RPCs, shared memory with mmap and
> mutexes/semaphores, messages passing through pipes as tunnels, MPI".
>
>  - A filelock cannot be used to prevent a second thread within the same
> process from reading from or writing to the environ[] array (or any other
> variable) or calling setenv/getenv while a first thread temporarily swaps the
> value in it.
>
>  - A remote procedure call cannot stop a second thread in the same process
> from reading the environ[] array (or any other ... (etc).
>
>  - An mmap'd shared memory block cannot stop a second thread  ... (etc).
>
>  - Passing a message through a pipe cannot stop a second thread ... (etc).
>
>  - A mutex/semaphore *could* do this, but only if every call to getenv/setenv
> and every direct access to the environ array were *also* wrapped in mutex lock
> calls.  This is not something you can work around in a library implementation
> of pexecute, it would require every author of every program that uses
> libiberty to modify their entire code.
>
>   The fact that you have suggested all those useless suggestions proves that
> you have not understood what we are discussing, which was how to temporarily
> alter the value of a global variable in one thread of a program without any
> other thread seeing the altered value, when we do not control the other
> threads because we are just a library function, not the application itself.
> The generic solution for this problem, which I mentioned in my original post,
> is a "critical section", which is a stretch of code that locks out the
> scheduler from scheduling any other threads of the process to run during the
> period the lock is held.
>
> > Do you permit me a question for you?
> >
> >    "Are important the suggestions?"
>
>   Their importance is proportional to the product of their relevance
> multiplied by their feasibility.  Your suggestions above were all irrelevant,
> except for the unfeasible one.  0*(anything) == (anything)*0 == 0*0 == 0.
>
>     cheers,
>       DaveK
> --
> Can't think of a witty .sigline today....

and you wrote too at start of this topic:

> "The vfork() function shall be equivalent to fork(), except that the behavior
> is undefined if the process created by vfork() either modifies any data other
> than a variable of type pid_t used to store the return value from vfork(), or
> returns from the function in which vfork() was called, or calls any other
> function before successfully calling _exit() or one of the exec family of
> functions."

Briefly, it's fork-like. It's about processes, not threads.
It's about parent and children processes.
And the another man talked about threads (critical section for threads).

   J.C.Pizarro "the noiser" (theirs freedoms that they want to stop me)

Re: libiberty/pex-unix vfork abuse?

[Gabriel Dos Reis]

"J.C. Pizarro" <jcpiza@gmail.com> writes:

| > But random suggestions based on something you read in school are useless
| 
| You're wrong. My suggestions are not based from school and are not useless.
| My suggestions are based from university, books, papers and internet

What is the difference?

-- Gaby

RE: libiberty/pex-unix vfork abuse?

[Dave Korn]

On 10 December 2007 20:01, Brian Dessent wrote:

> Andreas Schwab wrote:
> 
>> Typically in a multithreaded environment vfork is mapped to fork anyway.
> 
> ...which is what I don't understand about this whole thread.  It seems
> Dave is seeing some strange behavior in Cygwin, but Cygwin's vfork =
> fork, there is no difference.  There used to be a vfork specialization
> in Cygwin, but it is broken and has not been enabled in quite a long
> time.

  Yes, I've noticed it's #ifdef'd out now I've been through the code more
thoroughly, and it's also the case that in the old version of gcc/libiberty I'm
using the manipulation of the environ variable isn't there either, so I don't
have a current problem to solve myself, but some of the embedded guys might want
to keep an eye out for it.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: libiberty/pex-unix vfork abuse?

[Daniel Jacobowitz]

On Mon, Dec 10, 2007 at 11:35:15PM +0100, Andreas Schwab wrote:
> Glibc will map vfork to fork in a multithreaded environment.

LinuxThreads used to.  NPTL does not; this caused various trouble for
GDB at the time.

-- 
Daniel Jacobowitz
CodeSourcery

Re: libiberty/pex-unix vfork abuse?

[Andreas Schwab]

Joe Buck <Joe.Buck@synopsys.COM> writes:

> While the standard's wording might need fixing, with every implementation
> of vfork I know of, there are no threads.  It's a mechanism for systems
> that don't support fork (or that can only do fork in a horribly
> inefficient way, say because there's no MMU, and no support for copy on
> write), but that support the creation of new processes.  It's just a
> cheat to support the traditional fork-followed-by-exec, an aid for porting
> Unix code to non-Unix systems.

vfork has been invented by Unix, it has nothing to do with porting.  It
was needed to avoid the overhead of copying the address space just to
throw the copy away during execve.  On modern systems the overhead is
almost nonexistent.

> The reason vfork blocks the parent until the child makes a new process
> or quits is because that's the only supported behavior on systems that
> support it; it is not really "blocking the parent" at all as there is
> only one process.

The only reason the parent needs to be suspended is because it shares
the stack with the child.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: libiberty/pex-unix vfork abuse?

[Andreas Schwab]

Daniel Jacobowitz <drow@false.org> writes:

> On Mon, Dec 10, 2007 at 11:18:57AM -0800, Joe Buck wrote:
>> While the standard's wording might need fixing, with every implementation
>> of vfork I know of, there are no threads.  It's a mechanism for systems
>> that don't support fork (or that can only do fork in a horribly
>> inefficient way, say because there's no MMU, and no support for copy on
>> write), but that support the creation of new processes.
>
> No, Dave's right.  On GNU/Linux you can have two threads running on
> different processors simultaneously calling vfork.  And even with an
> MMU it is considerably more efficient than requiring setup of a new
> copy-on-write page table.

Glibc will map vfork to fork in a multithreaded environment.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: libiberty/pex-unix vfork abuse?

[Ian Lance Taylor]

Joe Buck <Joe.Buck@synopsys.COM> writes:

> I don't think it's wise to waste time fixing theoretical bugs
> exposed by close reading of the standard.  Now, messing with environ
> with vfork will mess up the parent process, and if that happens it's a
> bug.  But getting around it by using fork will harm portability, as the
> only reason to bother with vfork at all is that fork might not be
> available.

That's not the only reason.  I used vfork because I measured
performance improvements with vfork over fork.  I can't remember
whether I did the measurements on GNU/Linux or on NetBSD.

Performance improvements are not particularly surprising.  Despite the
fact that, as the Open Group specification suggests, vfork is a broken
interface, it was implemented to be faster than fork/exec, and it is
faster.

Ian

Re: libiberty/pex-unix vfork abuse?

[Joe Buck]

On Mon, Dec 10, 2007 at 02:22:45PM -0500, Daniel Jacobowitz wrote:
> On Mon, Dec 10, 2007 at 11:18:57AM -0800, Joe Buck wrote:
> > While the standard's wording might need fixing, with every implementation
> > of vfork I know of, there are no threads.  It's a mechanism for systems
> > that don't support fork (or that can only do fork in a horribly
> > inefficient way, say because there's no MMU, and no support for copy on
> > write), but that support the creation of new processes.
> 
> No, Dave's right.  On GNU/Linux you can have two threads running on
> different processors simultaneously calling vfork.  And even with an
> MMU it is considerably more efficient than requiring setup of a new
> copy-on-write page table.

Yes, that's true.  And of course some implementation might map vfork to
fork, which complies with standards.  I only meant to talk about races
between parent and child "process".

Re: libiberty/pex-unix vfork abuse?

[Brian Dessent]

Andreas Schwab wrote:

> Typically in a multithreaded environment vfork is mapped to fork anyway.

...which is what I don't understand about this whole thread.  It seems
Dave is seeing some strange behavior in Cygwin, but Cygwin's vfork =
fork, there is no difference.  There used to be a vfork specialization
in Cygwin, but it is broken and has not been enabled in quite a long
time.

Brian

Re: libiberty/pex-unix vfork abuse?

[Andreas Schwab]

"Dave Korn" <dave.korn@artimi.com> writes:

> On 07 December 2007 20:52, Andreas Schwab wrote:
>
>> "Dave Korn" <dave.korn@artimi.com> writes:
>> 
>>>   Perhaps we could work around this case by setting environ in the parent
>>> before the vfork call and restoring it afterward, but we'd need kind of
>>> serialisation there,
>> 
>> Do we?  vfork should block the parent until the child calls execve or
>> exit.
>
>   I don't see anything in posix that suggests that?

That is true, but technically it is rather difficult to implement a true
vfork without blocking the parent between vfork and exec/exit, since
that these are the only synchronisation points.

> I'm worrying in this case about races between multiple threads in the
> parent vfork'ing multiple children,

Typically in a multithreaded environment vfork is mapped to fork anyway.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: libiberty/pex-unix vfork abuse?

[Daniel Jacobowitz]

On Mon, Dec 10, 2007 at 11:18:57AM -0800, Joe Buck wrote:
> While the standard's wording might need fixing, with every implementation
> of vfork I know of, there are no threads.  It's a mechanism for systems
> that don't support fork (or that can only do fork in a horribly
> inefficient way, say because there's no MMU, and no support for copy on
> write), but that support the creation of new processes.

No, Dave's right.  On GNU/Linux you can have two threads running on
different processors simultaneously calling vfork.  And even with an
MMU it is considerably more efficient than requiring setup of a new
copy-on-write page table.

-- 
Daniel Jacobowitz
CodeSourcery

Re: libiberty/pex-unix vfork abuse?

[Joe Buck]

On Mon, Dec 10, 2007 at 06:32:08PM -0000, Dave Korn wrote:
> On 07 December 2007 20:52, Andreas Schwab wrote:
> 
> > "Dave Korn" <dave.korn@artimi.com> writes:
> > 
> >>   Perhaps we could work around this case by setting environ in the parent
> >> before the vfork call and restoring it afterward, but we'd need kind of
> >> serialisation there,
> > 
> > Do we?  vfork should block the parent until the child calls execve or
> > exit.
> 
>   I don't see anything in posix that suggests that?  I'm worrying in this case
> about races between multiple threads in the parent vfork'ing multiple children,
> not about the child-parent interaction, which this suggestion was a workaround
> for.  (But in any case, the subsequent suggestion by Ross to just fall back on
> fork instead of vfork when the environment needs setting is probably the
> simplest and most robust, obsoleting this earlier suggestion of mine).

While the standard's wording might need fixing, with every implementation
of vfork I know of, there are no threads.  It's a mechanism for systems
that don't support fork (or that can only do fork in a horribly
inefficient way, say because there's no MMU, and no support for copy on
write), but that support the creation of new processes.  It's just a
cheat to support the traditional fork-followed-by-exec, an aid for porting
Unix code to non-Unix systems.  The reason vfork blocks the parent until
the child makes a new process or quits is because that's the only
supported behavior on systems that support it; it is not really "blocking
the parent" at all as there is only one process.

I don't think it's wise to waste time fixing theoretical bugs
exposed by close reading of the standard.  Now, messing with environ
with vfork will mess up the parent process, and if that happens it's a
bug.  But getting around it by using fork will harm portability, as the
only reason to bother with vfork at all is that fork might not be
available.

RE: libiberty/pex-unix vfork abuse?

[Dave Korn]

On 07 December 2007 20:52, Andreas Schwab wrote:

> "Dave Korn" <dave.korn@artimi.com> writes:
> 
>>   Perhaps we could work around this case by setting environ in the parent
>> before the vfork call and restoring it afterward, but we'd need kind of
>> serialisation there,
> 
> Do we?  vfork should block the parent until the child calls execve or
> exit.

  I don't see anything in posix that suggests that?  I'm worrying in this case
about races between multiple threads in the parent vfork'ing multiple children,
not about the child-parent interaction, which this suggestion was a workaround
for.  (But in any case, the subsequent suggestion by Ross to just fall back on
fork instead of vfork when the environment needs setting is probably the
simplest and most robust, obsoleting this earlier suggestion of mine).

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: libiberty/pex-unix vfork abuse?

[Andreas Schwab]

"Dave Korn" <dave.korn@artimi.com> writes:

>   Perhaps we could work around this case by setting environ in the parent
> before the vfork call and restoring it afterward, but we'd need kind of
> serialisation there,

Do we?  vfork should block the parent until the child calls execve or
exit.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: libiberty/pex-unix vfork abuse?

[Ross Ridge]

Dave Korn writes:
>  Perhaps we could work around this case by setting environ in the parent
> before the vfork call and restoring it afterward, but we'd need kind of
> serialisation there, and I don't know how to do a critical section using
> pthreads/posix.

A simple solution would be to call fork() instead of vfork() when changing
the environment.

					Ross Ridge

Re: libiberty/pex-unix vfork abuse?

[Ian Lance Taylor]

"Dave Korn" <dave.korn@artimi.com> writes:

> > On the other hand, the setting of environ is very dubious and is
> > likely to break on real systems.  The code should be changed to call
> > execve instead.  Unfortunately there is no standard execvpe function.
> > Fortunately gcc never uses the variant which sets environ.  Offhand
> > I'm not sure what does.
> 
>   Perhaps we could work around this case by setting environ in the parent
> before the vfork call and restoring it afterward, but we'd need kind of
> serialisation there, and I don't know how to do a critical section using
> pthreads/posix.

The setting of environ came in here:

http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00377.html

Mark, setting the global environ variable won't work correctly on Unix
when using vfork.  Your e-mail refers to the prelinker.  The prelinker
sources that I have don't use the pex routines.  Do your prelinker
sources require setting the environment when using the PEX_SEARCH flag
while setting the environment?  If not, I think the simple approach is
to disallow that flag for pex_run_in_environment, to not set environ,
and to use execve instead.

Ian

RE: libiberty/pex-unix vfork abuse?

[Dave Korn]

On 07 December 2007 16:59, Ian Lance Taylor wrote:

> "Dave Korn" <dave.korn@artimi.com> writes:
> 
>>   Note the several calls to dup2() and close(), which seem to me to be
>> "calls [to] any other function", and the setting of environ, which seem to
>> me to be modification of "any data other than a variable of type pid_t
>> used to store the return value from vfork()".
> 
> Despite the standardese, vfork was invented to support calling
> dup/dup2 before calling exec.  Without that feature, it would be
> nearly useless.  Any actual implementation of vfork must support
> calling dup/dup2, or it will break all real programs which use vfork.

  Ah, right, hence the 'defensive coding' relating to the fdtab in cygwin.  I
can see how hard it would be to do the standard unix fork-and-fd-swap dance
without that.  (Should possibly Cc. the austin group ml and suggest a revision
to the wording, assuming they aren't deciding to remove it altogether).

> On the other hand, the setting of environ is very dubious and is
> likely to break on real systems.  The code should be changed to call
> execve instead.  Unfortunately there is no standard execvpe function.
> Fortunately gcc never uses the variant which sets environ.  Offhand
> I'm not sure what does.

  Perhaps we could work around this case by setting environ in the parent
before the vfork call and restoring it afterward, but we'd need kind of
serialisation there, and I don't know how to do a critical section using
pthreads/posix.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: libiberty/pex-unix vfork abuse?

[Ian Lance Taylor]

"Dave Korn" <dave.korn@artimi.com> writes:

>   Note the several calls to dup2() and close(), which seem to me to be "calls
> [to] any other function", and the setting of environ, which seem to me to be
> modification of "any data other than a variable of type pid_t used to store
> the return value from vfork()".

Despite the standardese, vfork was invented to support calling
dup/dup2 before calling exec.  Without that feature, it would be
nearly useless.  Any actual implementation of vfork must support
calling dup/dup2, or it will break all real programs which use vfork.

On the other hand, the setting of environ is very dubious and is
likely to break on real systems.  The code should be changed to call
execve instead.  Unfortunately there is no standard execvpe function.
Fortunately gcc never uses the variant which sets environ.  Offhand
I'm not sure what does.

Ian

libiberty/pex-unix vfork abuse?

[Dave Korn]

    Hey all,

  This is what posix says about vfork:

http://www.opengroup.org/onlinepubs/000095399/functions/vfork.html
"The vfork() function shall be equivalent to fork(), except that the behavior
is undefined if the process created by vfork() either modifies any data other
than a variable of type pid_t used to store the return value from vfork(), or
returns from the function in which vfork() was called, or calls any other
function before successfully calling _exit() or one of the exec family of
functions."

  This is how pex-unix.c uses vfork:

static long
pex_unix_exec_child (struct pex_obj *obj, int flags, const char *executable,
		     char * const * argv, char * const * env,
                     int in, int out, int errdes,
		     int toclose, const char **errmsg, int *err)
{
  pid_t pid;

  /* We declare these to be volatile to avoid warnings from gcc about
     them being clobbered by vfork.  */
  volatile int sleep_interval;
  volatile int retries;

  sleep_interval = 1;
  pid = -1;
  for (retries = 0; retries < 4; ++retries)
    {
      pid = vfork ();
      if (pid >= 0)
	break;
      sleep (sleep_interval);
      sleep_interval *= 2;
    }

  switch (pid)
    {
    case -1:
      *err = errno;
      *errmsg = VFORK_STRING;
      return -1;

    case 0:
      /* Child process.  */
      if (in != STDIN_FILE_NO)
	{
	  if (dup2 (in, STDIN_FILE_NO) < 0)
	    pex_child_error (obj, executable, "dup2", errno);
	  if (close (in) < 0)
	    pex_child_error (obj, executable, "close", errno);
	}
      if (out != STDOUT_FILE_NO)
	{
	  if (dup2 (out, STDOUT_FILE_NO) < 0)
	    pex_child_error (obj, executable, "dup2", errno);
	  if (close (out) < 0)
	    pex_child_error (obj, executable, "close", errno);
	}
      if (errdes != STDERR_FILE_NO)
	{
	  if (dup2 (errdes, STDERR_FILE_NO) < 0)
	    pex_child_error (obj, executable, "dup2", errno);
	  if (close (errdes) < 0)
	    pex_child_error (obj, executable, "close", errno);
	}
      if (toclose >= 0)
	{
	  if (close (toclose) < 0)
	    pex_child_error (obj, executable, "close", errno);
	}
      if ((flags & PEX_STDERR_TO_STDOUT) != 0)
	{
	  if (dup2 (STDOUT_FILE_NO, STDERR_FILE_NO) < 0)
	    pex_child_error (obj, executable, "dup2", errno);
	}

      if (env)
        environ = (char**) env;

      if ((flags & PEX_SEARCH) != 0)
	{
	  execvp (executable, argv);
	  pex_child_error (obj, executable, "execvp", errno);
	}
      else
	{
	  execv (executable, argv);
	  pex_child_error (obj, executable, "execv", errno);
	}



  Note the several calls to dup2() and close(), which seem to me to be "calls
[to] any other function", and the setting of environ, which seem to me to be
modification of "any data other than a variable of type pid_t used to store
the return value from vfork()".  The comment on pex_child_error (which uses
write() to do output) gives a hint at the thinking here:


/* Report an error from a child process.  We don't use stdio routines,
   because we might be here due to a vfork call.  */

static void
pex_child_error (struct pex_obj *obj, const char *executable,
		 const char *errmsg, int err)
{
#define writeerr(s) (void) write (STDERR_FILE_NO, s, strlen (s))
  writeerr (obj->pname);


  But I don't see any reason to assume the restriction only applies to f*()
stdio functions, in fact by my reading I don't think you're [technically] even
allowed to call a pure const inline function that's part of your own code.  (I
assume that that would in fact work ok in practice at least most of the time).

  Are we ok here?  This code seems like it's doing the wrong thing to me.  As
far as I can tell, we only get away with this in cygwin because of paranoid
defensive programming that backs up the fd table before running the vfork'd
child's code in the parent's context up to the first exec*() call, and then
restores it afterward, but I'm fairly sure that this implementation will still
overwrite the parent's environment.... which could well be Not A Good Thing!


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....