On Thu, 10 Dec 2009, Linda Messerschmidt wrote:
Also...
On Thu, Dec 10, 2009 at 9:50 AM, Bernd Walter <ti...@cicely7.cicely.de> wrote:
I use fork myself, because it is easier sometimes, but people writing
big programms such as squid should know better.
If squid doesn't use vfork they likely have a reason.
Actually they are probably going to switch to vfork(). They were
previously not using it because they thought there was some ambiguity
about whether it was going to be around long term.
Well, the worst that would likely happen to vfork() is it would become an
alias of fork(), and you'd be back to where you are now (or better if
fork() were fixed in the meantime). I'd be more worried about the
mysterious bugs which it's so easy to introduce with vfork() if you do
anything at all nontrivial before exec() and accidentally touch the
parent's memory.
What about using posix_spawn(3)? This is implemented in terms of
vfork(), so you'll gain the same performance advantages, but it avoids
many of vfork's pitfalls. Also, since it's a POSIX standard function, you
needn't worry that it will go away or change its semantics someday.
I actually am not a huge fan of vfork() since it stalls the parent
process until the child exec()'s.
If you're doing so much work between vfork() and exec() that this delay is
significant, then I would think you're really abusing vfork().
To me, this case actually highlights why that's an issue. If the
explanation is that stuff is happening in the parent process between
fork() and the child's exec() causes the fragmentation, that's stuff
that would be deferred in a vfork() regime, with unknown potential
consequences. (At a minimum, decreased performance.)
Not necessarily. In the fork() case, presumably copy-on-write is to blame
for the fragmentation. In the vfork() case, there's no copy at all.
--
Nate Eldredge
n...@thatsmathematics.com
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
