[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Use spawn() in GNU Make on Cygwin, updated

From: Eli Zaretskii
Subject: Re: [PATCH] Use spawn() in GNU Make on Cygwin, updated
Date: Fri, 16 Aug 2013 22:16:38 +0300

> Date: Fri, 16 Aug 2013 22:52:55 +0400
> From: Pavel Fedin <address@hidden>
> Cc: Christopher Faylor <address@hidden>,
>       address@hidden
>  To  me  current  situation  looks non-constructive. You say: "Current
> implementation   works,  new  implementation  theoretically  may  fail
> (because   it's   new),   so   we   must  not  change the code". Is it
> correct developer's approach ? Yes, changes sometimes introduce bugs,
> that's OK. Doesn't  this  mean  that we just need to add some tests ?
> Can anyone (opponents)  give  ideas  on  what exactly needs  to be
> tested ? I can extend make's test suite then.

You are missing the point.  The problem with this change is not that
it changes code.  The problem is that it replaces the fork/exec
paradigm, which implements a well-known set of requirements, with a
call to 'spawn', whose requirements are different and much less known
(because it is not covered by any standard).  Moreover, while
fork/exec have the same functionality in Cygwin as they have on other
Posix platforms, 'spawn' has no equivalents on Posix platforms, and
the mainstream Make developers know nothing about it.  Since Cygwin
users expect Cygwin programs, Make included, to behave exactly like
they do on Posix platforms, introducing an interface that is not used
on Posix will cause a divergence between the Cygwin behavior and the
Posix behavior of GNU Make.

Please re-read again what Paul wrote: the code in GNU Make between the
call to 'fork' and the subsequent call to 'exec' is the source of
concern here.  Even if you prove by inspection of the current code of
'spawn' in Cygwin's library that the same code runs in 'spawn', any
future changes in GNU Make between these two calls, or any changes in
the implementation of 'spawn', will invalidate that proof.  IOW, even
if today the two versions are exactly identical (and I'm not sure they
are), they can become different at any time in the future, without any

reply via email to

[Prev in Thread] Current Thread [Next in Thread]