Superpages on amd64 FreeBSD 7.2-STABLE

[Adrian Chadd]

Depending upon the IPC method being used, the fork() may be followed
with calls to socket() and connect(), which may take a while.

The main process will stall if you have a busy proxy and there's some
temporary shortage of something which makes connect() take longer than
usual, the main process will stall, potentially causing the shortage
to become worse.

2c,


Adrian
(With his (ex-, kinda) Squid hacker hat on.)

2009/12/10 Linda Messerschmidt <linda.messerschmidt at gmail.com>:
> Also...
>
> On Thu, Dec 10, 2009 at 9:50 AM, Bernd Walter <ticso at 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.
>
> I actually am not a huge fan of vfork() since it stalls the parent
> process until the child exec()'s.
>
> 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.)
>
> But that's personal and largely uninformed opinion. :)
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>