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 _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
