Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 09 Dec 1998 16:51:57 -0800
From:      Cy Schubert <cschuber@uumail.gov.bc.ca>
To:        Alfred Perlstein <bright@hotjobs.com>
Cc:        Alberto de Poo Bas <adepoo@tamnet.com.mx>, stable@FreeBSD.ORG
Subject:   Re: Weird Process Timings 
Message-ID:  <199812100052.QAA22423@passer.osg.gov.bc.ca>
In-Reply-To: Your message of "Wed, 09 Dec 1998 15:26:13 EST." <Pine.BSF.4.05.9812091522390.27793-100000@bright.fx.genx.net> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.05.9812091522390.27793-100000@bright.fx.genx.net>
, Alfre
d Perlstein writes:
> On Wed, 9 Dec 1998, Alberto de Poo Bas wrote:
> 
> > 
> > I have a machine with 2.2.6 and the 31dec69 date it show when someone have
> > a process with bash. Maybe is something with bash?
> > 
> 
> Probably not, i don't see how bash could subvert the kernel... unless
> something was broken.
> 
> that, and another friend is complaining about problems.
> 
> I'm beginning to suspect someone messed up sysctl because someone just
> told me:
> 
> "/usr/share/mk/bsd.port.mk", line 401: warning: "sysctl -n kern.osreldate"
> returned non-zero status  
> 
> something weird with pcbs?  i don't have time to track it down, and told
> them to either ride out the problem (hoping someone takes notice) or cvsup
> backwards one week and try that.

I believe its got something to do with bash forking.  Try;

ps aux > foo
ps aux | cat > foo
ps aux | cat | cat > foo

Notice that the number of "31Dec69" bash processes corresponds to the 
number of pipes.  Also notice that the cat processes are not listed.  I 
cannot duplicate this with sh or csh.  I notice that pdksh will behave 
the same as bash.  Pdksh and bash are dynamically linked while sh and 
csh are statically linked.  I suspect that dynamic linking causes 
fork() to be "slower" thereby allowing a window of opportunity to see 
the shell listed in a ps listing before the process structures have 
been completely set up.  This can be proven by:

(sleep 1; ps aux) | cat | cat | egrep 'cat|bash'
	or
(echo foo; ps aux) | cat | cat | egrep 'cat|bash'

Notice that the "31Dec69" processes go away and ps now runs after the 
fork() has completed.

Without looking at the kernel source (and one of the FreeBSD wizards 
can correct me here), I suspect that 4.4BSD is optimizing fork() by 
allowing the parent to continue to run without having completely set up 
the child while buffering output in the pipe until it is requested by 
the child.  It is an optimum way to manage throughput, with a minor 
drawback.

Interestingly enough dynamically linked shells don't exhibit this under 
Solaris, DUNIX, or Linux.  Can this mean that 4.4BSD's fork() has 
better throughput than the others?  If that's the case, it's probably a 
small price to pay.


Regards,                       Phone:  (250)387-8437
Cy Schubert                      Fax:  (250)387-5766
Open Systems Group          Internet:  Cy.Schubert@uumail.gov.bc.ca
ITSD                                   Cy.Schubert@gems8.gov.bc.ca
Government of BC            
                                       



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812100052.QAA22423>