Re: Copied from another newsgroup - Solaris

This is a discussion on Re: Copied from another newsgroup - Solaris ; GreyCloud wrote: > Any comments on this? > > > fork() is supposed to make a copy of the process that executes > > it, including all data. Actually doing this would burn gargantuan > > amounts of memory and ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Re: Copied from another newsgroup

  1. Re: Copied from another newsgroup

    GreyCloud wrote:
    > Any comments on this?
    >
    > > fork() is supposed to make a copy of the process that executes
    > > it, including all data. Actually doing this would burn gargantuan
    > > amounts of memory and is Not Done.
    > >
    > > Instead, fork() makes a sort of 'virtual copy'; the new process
    > > shares the memory of the old, but the VM is configured so that
    > > whenever any memory is changed by either process, it mades
    > > a private copy of *that* page, on demand.
    > >
    > > Making a private copy means allocating a page of storage
    > > for it, and when swap is exhausted, this allocation should
    > > fail.
    > >
    > > But it cannot fail. It is now too late; fork() has returned success
    > > *already*, to both processes, and it cannot now return failure.
    > > You'd need a time machine.
    > >

    >
    > Written by an MSCE. (or whatever they're called)
    >


    Source?

  2. Re: Copied from another newsgroup

    Wayne wrote:
    > GreyCloud wrote:
    >> Any comments on this?
    >>
    >> > fork() is supposed to make a copy of the process that executes
    >> > it, including all data. Actually doing this would burn gargantuan
    >> > amounts of memory and is Not Done.
    >> >
    >> > Instead, fork() makes a sort of 'virtual copy'; the new process
    >> > shares the memory of the old, but the VM is configured so that
    >> > whenever any memory is changed by either process, it mades
    >> > a private copy of *that* page, on demand.
    >> >
    >> > Making a private copy means allocating a page of storage
    >> > for it, and when swap is exhausted, this allocation should
    >> > fail.
    >> >
    >> > But it cannot fail. It is now too late; fork() has returned success
    >> > *already*, to both processes, and it cannot now return failure.
    >> > You'd need a time machine.
    >> >

    >>
    >> Written by an MSCE. (or whatever they're called)
    >>

    >
    > Source?


    I don't understand where the difficulty occurs (apart from the obvious
    misunderstanding of how copy on write operates.) The fork succeeds and a new
    thread of execution runs so that's OK. The new process runs out of memory
    which is an entirely different problem. As the fork has no idea what the
    new process is going to do (it may immediately exec another program - which
    is why you don't just duplicate the old memory map) there is no way it can
    predict future problems.

    Could this be someone who doesn't understand the difference between fork and
    exec?

  3. Re: Copied from another newsgroup

    News wrote:
    > Wayne wrote:
    >> GreyCloud wrote:
    >>> Any comments on this?
    >>>
    >>> > fork() is supposed to make a copy of the process that executes
    >>> > it, including all data. Actually doing this would burn gargantuan
    >>> > amounts of memory and is Not Done.
    >>> >
    >>> > Instead, fork() makes a sort of 'virtual copy'; the new process
    >>> > shares the memory of the old, but the VM is configured so that
    >>> > whenever any memory is changed by either process, it mades
    >>> > a private copy of *that* page, on demand.
    >>> >
    >>> > Making a private copy means allocating a page of storage
    >>> > for it, and when swap is exhausted, this allocation should
    >>> > fail.
    >>> >
    >>> > But it cannot fail. It is now too late; fork() has returned success
    >>> > *already*, to both processes, and it cannot now return failure.
    >>> > You'd need a time machine.
    >>> >
    >>>
    >>> Written by an MSCE. (or whatever they're called)
    >>>

    >> Source?

    >
    > I don't understand where the difficulty occurs (apart from the obvious
    > misunderstanding of how copy on write operates.) The fork succeeds and a new
    > thread of execution runs so that's OK. The new process runs out of memory
    > which is an entirely different problem. As the fork has no idea what the
    > new process is going to do (it may immediately exec another program - which
    > is why you don't just duplicate the old memory map) there is no way it can
    > predict future problems.
    >
    > Could this be someone who doesn't understand the difference between fork and
    > exec?


    I just want to read the thread.

  4. Re: Copied from another newsgroup

    |> > But on Windows, CreateProcessEx() either makes a new
    |> > process or fails. In those places where it uses Copy-on-Write,
    |> > it reserves the swap space in advance, or fails if it can't.
    |> >
    |> > fork() could do this, but because fork() uses copy-on-write
    |> > for *the whole process*, this would burn absurd amounts of
    |> > swap space; therefore this is not done.

    Actually, on Solaris the swap space *is* all reserved at fork() time to make
    sure you don't fail in this way later on. Apparently Linux doesn't though.

    There's also vfork() for the cases where you don't want to allocate
    all of this space, or can't because the process doing the fork is too
    big. Most fork-then-exec uses vfork. vfork() also avoids the work
    needed to set up all of the copy-on-write info. But it has a few other
    restrictions...

    Finally, as of Solaris 10, there's also posix_spawn() which presumably
    is similar to CreateProcessEx().

    Hugh.


  5. Re: Copied from another newsgroup

    Wayne wrote:

    > GreyCloud wrote:
    >
    >> Any comments on this?
    >>
    >> > fork() is supposed to make a copy of the process that executes
    >> > it, including all data. Actually doing this would burn gargantuan
    >> > amounts of memory and is Not Done.
    >> >
    >> > Instead, fork() makes a sort of 'virtual copy'; the new process
    >> > shares the memory of the old, but the VM is configured so that
    >> > whenever any memory is changed by either process, it mades
    >> > a private copy of *that* page, on demand.
    >> >
    >> > Making a private copy means allocating a page of storage
    >> > for it, and when swap is exhausted, this allocation should
    >> > fail.
    >> >
    >> > But it cannot fail. It is now too late; fork() has returned success
    >> > *already*, to both processes, and it cannot now return failure.
    >> > You'd need a time machine.
    >> >

    >>
    >> Written by an MSCE. (or whatever they're called)
    >>

    >
    > Source?

    I tracked it to a thread in "comp.sys.mac.advocacy".

    Seemed to be yet another "My OS is bigger than your OS" thread, I
    stopped scanning it before the boredom became terminal.

    Cheers,
    Gary B-)

    --
    __________________________________________________ ____________________________
    Armful of chairs: Something some people would not know
    whether you were up them with or not
    - Barry Humphries

  6. Re: Copied from another newsgroup

    usenet@mcintyreweb.com writes in alt.solaris.x86:
    |Finally, as of Solaris 10, there's also posix_spawn() which presumably
    |is similar to CreateProcessEx().

    An article explaining all this was recently posted on Sun's developer
    pages:
    http://developers.sun.com/solaris/ar...ubprocess.html

    --
    Alan Coopersmith * alanc@alum.calberkeley.org * Alan.Coopersmith@Sun.COM
    http://blogs.sun.com/alanc/ * http://people.freedesktop.org/~alanc/
    http://del.icio.us/alanc/ * http://www.csua.berkeley.edu/~alanc/
    Working for, but definitely not speaking for, Sun Microsystems, Inc.

+ Reply to Thread