Re:If everything in Unix development is POSIX, what the hell...
by tedunangst on Sunday January 02, 2011 @11:55AM
(#2060342)
vfork is probably worse because you have to be very careful if exec fails. Calling a function to log the error is likely to mess up the parent's memory.
Re:If everything in Unix development is POSIX, what the hell...
by burgerbrain on Sunday January 02, 2011 @03:15PM
(#2060883)
vforks restrictions mean that in most cases where fork is used in unix development besides the trivial fork/exec combination it won't be the proper choice.
Every single major operating system except one has fork. Colour me not very concerned.
That looks to be some questionable phrasing from the article.
Yes, fork() is a system call on many platforms, but not on all.
And fork() is not ubiquitous. If anything, it's one of the common and can be one of the more intractable sources of porting problems within C code.
fork() does rather more than many C programmers might realize. About 5 or 10% of the calls I've encountered in the many C applications I've ported will use fork() for most or all of what it can do. The remaining calls throw that context away, and can often be equally or better served with vfork()/exec() or some other C call.
Those applications that use fork() for what it can do can be and usually are more difficult to port to the various platforms that lack copy-on-read virtual memory.