Georg Nikodym writes:
| When a UNIX process wants to create a child, it fork()s and exec()s.
| The fork() duplicates the parent's address space. This was seen as
| silly when 9 times out of 10 the child simply calls exec and thus was
| born vfork(). vfork() has this problem, though that the child briefly
| runs in the parents address space. The implications of this statement
| are serious and have resulted in two things. First, standards authors
| have had no choice but to say that you can't guarantee anything aside
| from exec() or _exit() will work. Second, application developers have
| been bitten by all kinds of nasty bugs and have shied away from vfork.
| The net result is that vfork() could probably be removed from the UNIX
| ABI and nobody would shed a tear.
Yes, I know. I got several emails on this topic and if point people to
vfork() it seems they don't see vfork() as a solution. In this case we
had a proccess doing a fork() when it had grown to 300MB. This was a
server and it would do fork() multiple times during its life.
| So, for those folks playing with 36MB mail attachments for which
| mmencode needs to be called as a subprocess, seems like vfork might
| not be so bad after all...
If you could your hacking a patch I could build a _Management Edition_
of XEmacs. ;-) In fact this was just to point out that there might be
other issues to solve first before move to 64 bit computing. WRT 64
bit OS 36MB are ridiculess (and I guess even 36GB are).
| Rather than shun vfork, perhaps careful examination and
| rationalization of all the code that gets run in the child after the
| [v]fork() would be a plan...
I agree here and I guess this will become a issue anyway. Most of the
people have just started using MIME together with XEmacs. The more
they use XEmacs with larger data the more they feel the need for
performance improvement. (I remember there was a discussion about W3
rendering machine a while ago.)
| Of course, the right answer is for UNIX at large to adopt the Plan 9
| rfork()...
I never got my hands on Plan 9 but a review in a magazine was rarely
talking about these internal things.
--Marcus