Subject: Re: fork1 and new stack
To: None <email@example.com>
From: David Laight <firstname.lastname@example.org>
Date: 04/26/2002 19:04:44
On Fri, Apr 26, 2002 at 07:35:26PM +0200, Emmanuel Dreyfus wrote:
> Another problem:
> I assumed that the child will not be scheduled until the parent returns
> to userland, and thus that I can setup the child after calling fork1().
> Is it true on a SMP system?
It isn't traditionally true on a non-smp system!
The child is usually scheduled first - because when it does
the expected exec() a smaller number of the COW pages actually
have to be copied.
This does have a slightly undesirable effect on certain daemons.
If the child doesn't sleep (eg all its pages are resident) , the parent
remains blocked at a (low) running priority rather than the higher
sleep priority it would have if blocked in select/poll.
This means that its priority is continually lowered by the
scheduler, causing the network connect requests to timeout (etc).
For a users point of view, this converts an overloaded server
into a dead one (rather than a slow one).
A 'fix' is to momentarily block the child (eg poll(0,0,1)) so
that the parent is scheduled and returns to its block point in
poll/select. This doesn't affect the number of COW copies since
the parent won't access many of its pages before the child finally
David Laight: email@example.com