[9fans] APE fork()

[9fans] APE fork()

[Sascha Retzki]

Hello list,

/sys/src/ape/lib/ap/plan9/fork.c does an 
	_RFORK(RFENVG|RFFDG|RFPROC);

Why not RFMEM? Imho on POSIX-fork(), the child shares the address-space with the parents.  

It is not that I really care myself, #include <lib9.h> fixes a lot of things,;) ,but I fear programmes which rely on that may not work. Is there a specific reason fork.c:fork() does not fork with RFMEM?


Mfg, Sascha

Re: [9fans] APE fork()

[Victor Nazarov]

Sascha Retzki wrote:

>Hello list,
>
>/sys/src/ape/lib/ap/plan9/fork.c does an 
>	_RFORK(RFENVG|RFFDG|RFPROC);
>
>Why not RFMEM? Imho on POSIX-fork(), the child shares the address-space with the parents.  
>
>It is not that I really care myself, #include <lib9.h> fixes a lot of things,;) ,but I fear programmes which rely on that may not work. Is there a specific reason fork.c:fork() does not fork with RFMEM?
>
>
>Mfg, Sascha
>  
>
rfork (2):
``RFMEM --- If set, the child and the parent will share data and bss 
segments. Otherwise, the child inherits a copy of those segments. Other 
segment types, in particular stack segments, will be unaffected. May be 
set only with RFPROC.''

POSIX-fork() copies data and bss segmets, child process doesn't share 
data with it's parent. There are POSIX-threads, SYSV-IPC to share memory.
--
Victor

Re: [9fans] APE fork()

[Sascha Retzki]

> POSIX-fork() copies data and bss segmets, child process doesn't share 
> data with it's parent. 

I thought it does share the segments. And I think I saw this behaviour on Linux and some BSDs.


Maybe my minds fools me again

Re: [9fans] APE fork()

[Charles Forsyth]

> I thought it does share the segments. And I think I saw this behaviour on Linux and some BSDs.

Linux:

NAME
       fork - create a child process

SYNOPSIS
       #include <sys/types.h>
       #include <unistd.h>

       pid_t fork(void);

DESCRIPTION
       fork  creates a child process that differs from the parent
       process only in its PID and PPID, and  in  the  fact  that
       resource  utilizations are set to 0.  File locks and pend­
       ing signals are not inherited.

       Under  Linux,  fork  is  implemented  using  copy-on-write
       pages,  so  the  only penalty incurred by fork is the time
       and memory required to duplicate the parent's page tables,
       and to create a unique task structure for the child.


of course, that's the Linux man page so it doesn't say what fork does, but
how it is implemented.  in fact, it doesn't share the data or stack segments;
clone by contrast will share everything.

perhaps BSD can shed more light:

     Fork() causes creation of a new process.  The new process (child process)
     is an exact copy of the calling process (parent process) except for the
     following:

	   o   The child process has a unique process ID.

	   o   The child process has a different parent process ID (i.e., the
	       process ID of the parent process).

	   o   The child process has its own copy of the parent's descriptors.
	       These descriptors reference the same underlying objects, so
	       that, for instance, file pointers in file objects are shared
	       between the child and the parent, so that an lseek(2) on a
	       descriptor in the child process can affect a subsequent read(2)
	       or write(2) by the parent.  This descriptor copying is also
	       used by the shell to establish standard input and output for
	       newly created processes as well as to set up pipes.

	   o   The child process' resource utilizations are set to 0; see
	       setrlimit(2).

	   o   All interval timers are cleared; see setitimer(2).


finally 7th edition UNIX, rather than its imitators:

     NAME
          fork  -  spawn new process

     SYNOPSIS
          fork( )

     DESCRIPTION
          Fork is the only way new processes are created.  The new
          process's core image is a copy of that of the caller of
          fork. The only distinction is the fact that the value
          returned in the old (parent) process contains the process ID
          of the new (child) process, while the value returned in the
          child is 0.  Process ID's range from 1 to 30,000.  This pro-
          cess ID is used by wait(2).

          Files open before the fork are shared, and have a common
          read-write pointer.  In particular, this is the way that
          standard input and output files are passed and also how
          pipes are set up.

Re: [9fans] APE fork()

[Victor Nazarov]

Sascha Retzki wrote:

>>POSIX-fork() copies data and bss segmets, child process doesn't share 
>>data with it's parent. 
>>    
>>
>
>I thought it does share the segments. And I think I saw this behaviour on Linux and some BSDs.
>
>
>Maybe my minds fools me again
>  
>
Fork copies memory, see man pages or google for
it.  When fork() occurs, child process inherits
the exact copy of parents memory at the time of
fork.  So child will see all changes and settings,
you have done _befor_ fork.  You may take this
behavior for sharing memory.

--

Victor

Re: Re: [9fans] APE fork()

[david bulkow]

On 8/12/06, Victor Nazarov <vir@comtv.ru> wrote:
> POSIX-fork() copies data and bss segmets, child process doesn't share
> data with it's parent.

vfork() causes both child and parent to share address space.  I
believe this was introduced to make the fork/exec sequence faster as
the address space COW didn't need to be setup.

Re: Re: [9fans] APE fork()

[Sascha Retzki]

> On 8/12/06, Victor Nazarov <vir@comtv.ru> wrote:
>> POSIX-fork() copies data and bss segmets, child process doesn't share
>> data with it's parent.
> 
> vfork() causes both child and parent to share address space.  I
> believe this was introduced to make the fork/exec sequence faster as
> the address space COW didn't need to be setup.

That's it. Thanks for clarify things.

Re: [9fans] APE fork()

[Victor Nazarov]

david bulkow wrote:

> On 8/12/06, Victor Nazarov <vir@comtv.ru> wrote:
>
>> POSIX-fork() copies data and bss segmets, child process doesn't share
>> data with it's parent.
>
>
> vfork() causes both child and parent to share address space.  I
> believe this was introduced to make the fork/exec sequence faster as
> the address space COW didn't need to be setup.
>
I think, it's BSD specific.
--
Victor

Re: Re: [9fans] APE fork()

[Russ Cox]

> On 8/12/06, Victor Nazarov <vir@comtv.ru> wrote:
> > POSIX-fork() copies data and bss segmets, child process doesn't share
> > data with it's parent.
>
> vfork() causes both child and parent to share address space.  I
> believe this was introduced to make the fork/exec sequence faster as
> the address space COW didn't need to be setup.

I always thought vfork was introduced because
copy-on-write hadn't been invented yet.

It's the only logical explanation.

Russ

Re: [9fans] APE fork()

[Leonardo Valencia]

Russ Cox wrote:
> 
> I always thought vfork was introduced because
> copy-on-write hadn't been invented yet.
> 
> It's the only logical explanation.
> 
> Russ
> 


It is the correct explanation, that was the only reason to justify one 
of the most dangerous system calls ever invented, all in the name of 
performance, so I was relieved when it was finally made synonymous to 
fork() in almost any decent Unix out there (with the exception of NetBSD 
that reintroduced it and Linux that copied it from them).

Regards,

-Leonardo Valencia

Re: Re: [9fans] APE fork()

[Brantley Coile]

BUGS section of 4th BSD manual, VFORK(2V)

 ``This system call may be unnecessary if the 
 system sharing mechanism allow fork
 to be implemented more efficiently''
 
 
>> On 8/12/06, Victor Nazarov <vir@comtv.ru> wrote:
>> > POSIX-fork() copies data and bss segmets, child process doesn't share
>> > data with it's parent.
>>
>> vfork() causes both child and parent to share address space.  I
>> believe this was introduced to make the fork/exec sequence faster as
>> the address space COW didn't need to be setup.
> 
> I always thought vfork was introduced because
> copy-on-write hadn't been invented yet.
> 
> It's the only logical explanation.
> 
> Russ

Re: Re: [9fans] APE fork()

[erik quanstrom]

actually, vfork was implemted (as i understand it) due to insufficient core.
fork used to swap the parent  to disk and continue with the child process.

vfork was efficient if the child finished before it's scheduling quanta was
used up.

- erik

On Sat Aug 12 12:24:41 CDT 2006, brantley@coraid.com wrote:
> BUGS section of 4th BSD manual, VFORK(2V)
> 
>  ``This system call may be unnecessary if the 
>  system sharing mechanism allow fork
>  to be implemented more efficiently''
>  
>  
> >> On 8/12/06, Victor Nazarov <vir@comtv.ru> wrote:
> >> > POSIX-fork() copies data and bss segmets, child process doesn't share
> >> > data with it's parent.
> >>
> >> vfork() causes both child and parent to share address space.  I
> >> believe this was introduced to make the fork/exec sequence faster as
> >> the address space COW didn't need to be setup.
> > 
> > I always thought vfork was introduced because
> > copy-on-write hadn't been invented yet.
> > 
> > It's the only logical explanation.
> > 
> > Russ

Re: [9fans] APE fork()

[Bakul Shah]

> actually, vfork was implemted (as i understand it) due to insufficient core.

IIRC, it was invented for csh.  Typically a shell forks and
then immediately execs a program so all that copying done by
fork was a total waste of time (even setting up copy-on-write
is a waste).  vfork avoided copying almost entirely.  csh
wouldn't diddle with the parent's memory so *for that one
application* the vfork hack was safe.  Of course, we can't
have a special syscall just for one program, can we and
people used it in other programs, lured by its efficiency but
not always fully understanding it.

> fork used to swap the parent  to disk and continue with the child process.

Not necessary unless you are running on a machine with *no*
mapping h/w or with memory just enough for a single process.

> vfork was efficient if the child finished before it's scheduling quanta was
> used up.

It was efficient regardless but dangerous.

Re: Re: [9fans] APE fork()

[Charles Forsyth]

> I always thought vfork was introduced because
> copy-on-write hadn't been invented yet.
> 
> It's the only logical explanation.

no, it was because they chose not to implement copy on write.
it had been invented long before that.
in fact, i found copy on write at least as easy to do for unix
as the grunge required for vfork (and it was more generally useful).
on some architectures you need to use copy on reference.
their paging data structures might have made it more difficult, i suppose;
they had them upside down compared to unix's requirements.

vfork also was specified so that if you relied on the sharing
except to implement a non-sharing fork, the effect was undefined.

Re: Re: [9fans] APE fork()

[erik quanstrom]

i couldn't find the references to vfork i was looking for quickly with google;
they were lost in vast arguments about vfork bugs.

- erik

On Sat Aug 12 14:54:40 CDT 2006, forsyth@terzarima.net wrote:
> > I always thought vfork was introduced because
> > copy-on-write hadn't been invented yet.
> > 
> > It's the only logical explanation.
> 
> no, it was because they chose not to implement copy on write.
> it had been invented long before that.
> in fact, i found copy on write at least as easy to do for unix
> as the grunge required for vfork (and it was more generally useful).
> on some architectures you need to use copy on reference.
> their paging data structures might have made it more difficult, i suppose;
> they had them upside down compared to unix's requirements.
> 
> vfork also was specified so that if you relied on the sharing
> except to implement a non-sharing fork, the effect was undefined.

Re: Re: [9fans] APE fork()

[Iruatã Souza]

http://www.netbsd.org/Documentation/kernel/vfork.html

Re: Re: [9fans] APE fork()

[erik quanstrom]

"it shaves several seconds off a build of libc on a 200MHz PPro".
and then they use gcc.  kind of defeats the purpose, doesn't it?

- erik

On Sun Aug 13 23:04:32 CDT 2006, iru.muzgo@gmail.com wrote:
> http://www.netbsd.org/Documentation/kernel/vfork.html

Re: [9fans] APE fork()

[Ronald G Minnich]

erik quanstrom wrote:
> "it shaves several seconds off a build of libc on a 200MHz PPro".
> and then they use gcc.  kind of defeats the purpose, doesn't it?

yes, but think about it. It's so important!

Why, a few seconds on a 200mhz machine is ... maybe .3 seconds on that 
kernel build on a new machine. If you add up those .3 seconds enough, it 
could be a year of your life.

ron

Re: [9fans] APE fork()

[erik quanstrom]

your new machine must be awful slow.  i thought you guys
were the folks with the fast computers. ☺

and what are you doing rebuilding stage1 gentoo every day?

On Mon Aug 14 09:44:46 CDT 2006, rminnich@lanl.gov wrote:
> erik quanstrom wrote:
> > "it shaves several seconds off a build of libc on a 200MHz PPro".
> > and then they use gcc.  kind of defeats the purpose, doesn't it?
> 
> yes, but think about it. It's so important!
> 
> Why, a few seconds on a 200mhz machine is ... maybe .3 seconds on that 
> kernel build on a new machine. If you add up those .3 seconds enough, it 
> could be a year of your life.
> 
> ron

Re: [9fans] APE fork()

[Ronald G Minnich]

erik quanstrom wrote:
> your new machine must be awful slow.  i thought you guys
> were the folks with the fast computers. ☺


I needed to add more :-) to that last one.

ron

Re: [9fans] APE fork()

[erik quanstrom]

ron, this might save your wrists from typing all those :-)

	; cat $home/lib/kbmap/fkeys
	0	59	'☺
	0	60	'☹
	; cat $home/lib/kbmap/fkeys > /dev/kbmap

☺ erik

On Mon Aug 14 10:17:37 CDT 2006, rminnich@lanl.gov wrote:
> erik quanstrom wrote:
> > your new machine must be awful slow.  i thought you guys
> > were the folks with the fast computers. ☺
> 
> 
> I needed to add more :-) to that last one.
> 
> ron

Re: [9fans] APE fork()

[Martin Neubauer]

* Ronald G Minnich (rminnich@lanl.gov) wrote:
> erik quanstrom wrote:
> >"it shaves several seconds off a build of libc on a 200MHz PPro".
> >and then they use gcc.  kind of defeats the purpose, doesn't it?
> 
> yes, but think about it. It's so important!
> 
> Why, a few seconds on a 200mhz machine is ... maybe .3 seconds on that 
> kernel build on a new machine. If you add up those .3 seconds enough, it 
> could be a year of your life.
> 
> ron

Yes, makes you forget the decade sacrificed to gcc...

Martin

Re: [9fans] APE fork()

[John Floren]

On 8/14/06, Martin Neubauer <m.ne@gmx.net> wrote:
> * Ronald G Minnich (rminnich@lanl.gov) wrote:
> > erik quanstrom wrote:
> > >"it shaves several seconds off a build of libc on a 200MHz PPro".
> > >and then they use gcc.  kind of defeats the purpose, doesn't it?
> >
> > yes, but think about it. It's so important!
> >
> > Why, a few seconds on a 200mhz machine is ... maybe .3 seconds on that
> > kernel build on a new machine. If you add up those .3 seconds enough, it
> > could be a year of your life.
> >
> > ron
>
> Yes, makes you forget the decade sacrificed to gcc...
>
> Martin
>
Spend days building Ricer Linux so you can save .2 seconds loading
Firefox... I have met guys who do this, and talk about how great it is
on their (new) machines. I ask them how long they'll have to keep
using Gentoo to make up for the day of compilation.
That said, I have done Gentoo on an old SPARCstation in hopes that it
would run nicely. Splack Linux turned out better.


John
-- 
"The first thing we do, let's kill all the lawyers" -- Shakespeare, Henry VI

Re: [9fans] APE fork()

[erik quanstrom]

i've got nothing but good things to say about gentoo.  but you can't
drink the cool-aid about performance.  really, you know the gentoo
performance weenies are wrong when they talk about rebuilding their
toolchain three times.

i like it because i can run wierd hardware and i don't have binary package 
dependency hell. (binary packages are untenable on a with dl libraries anyway.)
also, they keep on top of security problems.

- erik

On Mon Aug 14 10:34:20 CDT 2006, slawmaster@gmail.com wrote:
> Spend days building Ricer Linux so you can save .2 seconds loading
> Firefox... I have met guys who do this, and talk about how great it is
> on their (new) machines. I ask them how long they'll have to keep
> using Gentoo to make up for the day of compilation.
> That said, I have done Gentoo on an old SPARCstation in hopes that it
> would run nicely. Splack Linux turned out better.

Re: [9fans] APE fork()

[Dave Lukes]

>  I always thought vfork was introduced because copy-on-write hadn't
>  been invented yet.
>
>  It's the only logical explanation.

That's almost funny.

DaveL

Re: Re: [9fans] APE fork()

[William Josephson]

On Sat, Aug 12, 2006 at 08:15:24AM -0700, Russ Cox wrote:
> I always thought vfork was introduced because
> copy-on-write hadn't been invented yet.
> 
> It's the only logical explanation.

Perhaps, but it isn't the one usually given.
It is usually billed as a way to make fork+exec faster/cheaper.