about 5 years ago i took a class on performance tuning Solaris.
The instructor claimed that fork was expensive because accounting is never
really turned off, just piped to /dev/null. there is no accounting overhead
for threads.
I never bothered to verify this, but now that this comes
On Tue, 2009-02-24 at 10:54 -0500, erik quanstrom wrote:
about 5 years ago i took a class on performance tuning Solaris.
The instructor claimed that fork was expensive because accounting is never
really turned off, just piped to /dev/null. there is no accounting
overhead for threads.
cfork is ~525 lines long and seems to take the curious tack of
forking all the lwps associated with a process.
that would be forkall(), not fork1()/fork()
my mistake. i assumed that since isfork1 was
a flag, that it was not the normal path through
the code. silly me.
so where's the
On Tue, 2009-02-24 at 11:22 -0500, erik quanstrom wrote:
cfork is ~525 lines long and seems to take the curious tack of
forking all the lwps associated with a process.
that would be forkall(), not fork1()/fork()
my mistake. i assumed that since isfork1 was
a flag, that it was not
It could have been the old accounting. Solaris 10
changed a lot of that and made things like microstate
accounting on by default, thus, possibly eliminating
the kind of bottlenecks the instructor was referring
to. More on that here:
On Fri, 20 Feb 2009, erik quanstrom wrote:
On Fri Feb 20 11:18:41 EST 2009, urie...@gmail.com wrote:
One of the main costs of dynamic linking is making fork much slower.
Even on linux statically linked binaries fork a few magnitude orders
faster than dynamically linked ones.
The main source
On Feb 19, 8:03 am, quans...@quanstro.net (erik quanstrom) wrote:
what's wrong with the tools-based approach
you're currently using?
this may be hard to believe coming from unix,
but your approach is what many tools do. nobody
links to a tcs library. one uses the tcs(1)
executable.
I believe that
1) Its too much trouble parsing the output everytime.
i don't buy that. that takes very little code. since you
have evidently already written the code, the cost
is zero.
(if you're worried about runtime, i measure parsing
time at 338ns on a core i7 920. cf. attached
One of the main costs of dynamic linking is making fork much slower.
Even on linux statically linked binaries fork a few magnitude orders
faster than dynamically linked ones.
The main source of anti-fork FUD turns out to be the alleged
'solution' to a problem that didn't exist until the geniuses
On Fri Feb 20 11:18:41 EST 2009, urie...@gmail.com wrote:
One of the main costs of dynamic linking is making fork much slower.
Even on linux statically linked binaries fork a few magnitude orders
faster than dynamically linked ones.
The main source of anti-fork FUD turns out to be the
Hello once again,
I was wondering whether if there are any libraries that I can include
to call vac and unvac directly from my C code. Currently I am
executing them in the shell using popen and capturing the output. I am
looking for better ways.
~Anoop
On Thu Feb 19 05:04:15 EST 2009, anooop.ano...@gmail.com wrote:
Hello once again,
I was wondering whether if there are any libraries that I can include
to call vac and unvac directly from my C code. Currently I am
executing them in the shell using popen and capturing the output. I am
12 matches
Mail list logo
