unless someone has done something "cute" to take advantage of
the memory-sharing semantics of vfork(), it's likely that
vfork() appeared in the code when that hack appeared in early
VAX Unix, about 25 years ago now. vfork() *ought* to be
transparently replacable by fork(), except for the code which
usually rides along with vfork() to work around the child
process's temporary use of the parent memory image without
breaking anything.
in most cases, it's better to design the launch of child
processes around a "spawn()" primitive which is intentionally
quite limited in that it promises about the creation of a child
process. that makes it *much* easier to port the code to systems
which are much less "unix-like" than one might desire given a choice.
frankly, i've always seen lots of #ifdefs in code as an
indication of a failure of design, engineering, or both. the
Software Tools was ported to a great many more and far more
disparate systems than just unix flavors without the aid of
#ifdefs in the applications. the system-specific libraries
hid all the system specific code required to export the required
semantics. the apps used that semantic interface and were
never the wiser. in some cases, almost an entire operating
system was implemented in the ST runtime library, in other
cases the code was relatively trivial. the fact that experience
was then ignored by the Unix crowd and now things like "configure"
are required today to manage the resulting bogosity is an
immense tragedy and a damning indictment of the craft displayed by it.
harumph
-mo
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers