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

[Pavel Fedin]

 Hello!

> I tried to explain that in my first response: 'fork' has a certain
> semantics and implements requirements that 'spawn' does not.

 Stop stop stop... Just to avoid misunderstanding here...
 fork() alone cannot be replaced with spawn(), yes. But as fas as i
understand, make does not use fork() alone. It uses fork() + exec() pair in
order to start external programs. As an end result, it is expected to run an
external executable with some defined environment (make sets environment in
the child then uses execvp() where external binary inherits it ). spawnvpe()
does absolutely the same, but in one shot. It runs an external executable
with predefined environment. Similar to fork(), spawnvpe() returns child's
PID, which allows to wait for its termination, send signals, etc. And of
course the started binary runs completely asynchronously, the same as with
fork() + exec().
 Windows actually does not allow to fork() cleanly by design (there's a full
explanation in http://www.cygwin.com/cygwin-ug-net/highlights.html ).
spawn() is much faster because the child is created from scratch with a new
executable, it does not have to be a clone of the parent, so it perfectly
wraps to legitimate CreateProcess() call.
 $(shell ) function also works fine, consequently we really perfectly handle
stdin/stdout (without this i don't see how command output would be
captured).
 So... 

> I'm not sure (Chris?).  In any case, you will see in the code that Make
> does a few things between the calls to 'fork' and 'exec'.  How can you
> be sure that 'spawn' does all that in exactly the same way?

 EMX/Cygwin code does absolutely the same things before calling spawn(). So
everything is set up. Yes, this means that this setup happens in parent too.
But - after all everything works fine. You have got feedbacks, modified make
works. Yes, there was a small problem discovered, but i have fixed it.

> And even if does that today, how can anyone be sure the Cygwin
> maintainers will not change it one day to do things in a slightly
> different way?

 Well, i hardly believe they can just change spawn() to something
incompatible. Despite it's not POSIX function, it actually has a
specification. It can be found here
http://msdn.microsoft.com/en-us/library/20y988d2(v=vs.80).aspx or here
http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/lib_ref/s/spawnvpe.html
. And, amongst other things, the specification clearly says that with
certain flags (P_OVERLAY) it's a complete equivalent to exec(). So,
consequently, all POSIX behavior which applies to exec(), automatically
applies to spawn(), it technically can't be the other way.
 After all, if some developer changes spawn() so that something stops
working, doesn't this mean that he has just introduced a bug and should fix
it ?

> > Well, if you really want it, changing child's environment can be
> > #ifdef'ed.
> 
> Yes, please.

 Ok, this is not a problem and in my next attempt i'll add this.

> You mean, rename 'status" to 'child_status'?  That's not a problem.

 Yes, please. If we don't come to full agreement, let's move in parts.
Actually i understand that you just want to make sure that the program
doesn't break. Perhaps some more testing would convince you. Actually i have
sent the new patch to Denis Excoffier (who reported the bug), but he doesn't
reply for some reason. If there'll be no response for some more time, i'll
retry posting the patch on Cygwin ML. I just don't want to be too much
annoying.
 I hope you also understand me right, i just want to avoid unnecessary
overcomplications. I think the change should be simple. The simpler the
modification, the more chances it's not broken somehow. This is the reason
why i reuse EMX code for Cygwin - since it's already there, i assume it's
already tested and works.

 By the way, who told that EMX is not POSIX ? Actually it is POSIX, it is
similar to Cygwin (it provides POSIX environment on top of non-POSIX one).
See http://en.wikipedia.org/wiki/EMX_(programming_environment) . I believe
it just misses fork() because of some underlying OS limitations. But IMHO
this is still POSIX. For example, there is a similar environment on AmigaOS
(and derivatives) called ixemul, it is also a full POSIX API, but also
cannot do fork() because the operating system does not work with address
spaces (it's similar to ucLinux or ELKS).
 So, being unable to fork() does not automatically mean being non-POSIX.
But, well, this is just an ideological argue and can be omitted.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia