Re: Environment of expansions and visibility of side-effect assignments

2017-07-27 Thread Joerg Schilling
wrote: > > > >On Solaris, vfork() is 3x faster than fork(), > > This depends very much on application. > > In Solaris, vfork() is more or less O(1) where fork() is a O(n) > where "n" is the size of the address space: each r/w page which isn't > shared needs to be marked "read-only" so the first

Re: Environment of expansions and visibility of side-effect assignments

2017-07-27 Thread Casper . Dik
>On Solaris, vfork() is 3x faster than fork(), This depends very much on application. In Solaris, vfork() is more or less O(1) where fork() is a O(n) where "n" is the size of the address space: each r/w page which isn't shared needs to be marked "read-only" so the first modification clones the

Re: Environment of expansions and visibility of side-effect assignments

2017-07-27 Thread Joerg Schilling
Jilles Tjoelker wrote: > > >From my metering, I know that on Solaris vfork() is 3x faster than fork() > > even tough the fork() implementation in SunOS uses CopyOnWrite since 1988. > > > As a result, I typically see aprox. 30% better performance with a > > "configure" > > run when vfork() is us

Re: Environment of expansions and visibility of side-effect assignments

2017-07-27 Thread Joerg Schilling
Robert Elz wrote: > When we have done a vfork, we do not generally make any mods that need > repair, and for what little is needed, the mechanism is already in place, > so nothing special is required. That is, when the vfork code was added This is something you should seek, but you usually can