[9fans] 9vx fork problem - Plan9

This is a discussion on [9fans] 9vx fork problem - Plan9 ; On 9vx, iostats suicides: term% iostats echo iostats 128: suicide: sys: trap: page fault pc=0x0000b21c Apparently, after a fork, a child retains it's parent's pid in _tos->pid. It isn't updated until the next syscall finishes with kexit. This is a ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: [9fans] 9vx fork problem

  1. [9fans] 9vx fork problem

    On 9vx, iostats suicides:

    term% iostats echo
    iostats 128: suicide: sys: trap: page fault pc=0x0000b21c

    Apparently, after a fork, a child retains it's parent's
    pid in _tos->pid. It isn't updated until the next syscall
    finishes with kexit.

    This is a problem if the child's first function call is
    malloc. When malloc locks it's pool, it stores the pid
    from _tos in a private area. After the kernel returns from
    the brk, _tos->pid has been corrected by the call to kexit.
    Punlock then fails because the pids don't match.

    I'm not sure of the best way to go about fixing this.

    Anthony


  2. Re: [9fans] 9vx fork problem

    > Thank you for the detailed reports.
    > It makes it very easy to fix the bugs!


    It really is my pleasure. Hunting bugs is
    one of my favorite pastimes. Well, that's
    not completely true: hunting bugs is usually
    only fun when dealing with code of a certain
    quality. Plan 9 makes the cut, as does all
    of your code.

    > + kexit(nil);


    I figured that would do it.

    Anthony


  3. Re: [9fans] 9vx fork problem

    > Apparently, after a fork, a child retains it's parent's
    > pid in _tos->pid.


    I think this is at the root of why 9vx cannot run on MS-Windows.

    I have been very slowly crawling towards an updated port of 9pm
    (p9p for windows as it was) learing the Windows API and the plan9
    kernel as I go.

    The one total show stopper is a lack of a real fork() in windows.

    This meant I chose to implement rfork(RFPROC) as somthing like vfork() -
    CreateThread() followed by CreateProcess() whilst the parent is blocked.
    This works in simple cases but breaks on rc(1). This is fixable by
    modifying the rc source (rc runs under windows in its inferno form anyway)
    but that is not the point.

    I implemented rfork(RFPROC|RFMEM) as CreateThread() with stack copy
    and relocation. This works well but means every windows-thread/plan9-psudo-proc
    has a different stack and thus _tos and _tos->pid won't work.

    This is OK, I just recompile every app using a modified malloc.c in libc
    but once again, if you break the purity of unmodified plan9 binaries then
    then you win almost noting over recompiling them on the target platform anyway -
    kencc syntax extensions not withstanding.

    I would love to get 9vx running on windows and if anyone has any ideas how to
    solve these problems then let me know.

    -Steve


  4. Re: [9fans] 9vx fork problem

    - Modify the kernel (it is based on Unix - even Microsoft says so)
    - Learn how Cygwin does it
    - Don't use real processes, like in Inferno

    On Jun 30, 2008, at 8:34 AM, Steve Simon wrote:

    >> Apparently, after a fork, a child retains it's parent's
    >> pid in _tos->pid.

    >
    > I think this is at the root of why 9vx cannot run on MS-Windows.
    >
    > I have been very slowly crawling towards an updated port of 9pm
    > (p9p for windows as it was) learing the Windows API and the plan9
    > kernel as I go.
    >
    > The one total show stopper is a lack of a real fork() in windows.
    >
    > This meant I chose to implement rfork(RFPROC) as somthing like
    > vfork() -
    > CreateThread() followed by CreateProcess() whilst the parent is
    > blocked.
    > This works in simple cases but breaks on rc(1). This is fixable by
    > modifying the rc source (rc runs under windows in its inferno form
    > anyway)
    > but that is not the point.
    >
    > I implemented rfork(RFPROC|RFMEM) as CreateThread() with stack copy
    > and relocation. This works well but means every windows-thread/plan9-
    > psudo-proc
    > has a different stack and thus _tos and _tos->pid won't work.
    >
    > This is OK, I just recompile every app using a modified malloc.c in
    > libc
    > but once again, if you break the purity of unmodified plan9 binaries
    > then
    > then you win almost noting over recompiling them on the target
    > platform anyway -
    > kencc syntax extensions not withstanding.
    >
    > I would love to get 9vx running on windows and if anyone has any
    > ideas how to
    > solve these problems then let me know.
    >
    > -Steve
    >




  5. Re: [9fans] 9vx fork problem

    >> Apparently, after a fork, a child retains it's parent's
    >> pid in _tos->pid.

    >
    > I think this is at the root of why 9vx cannot run on MS-Windows.


    No, it's not. The words fork and pid in that sentence
    are concepts completely internal to 9vx. The host OS,
    be it OS X or Linux or Windows, has absolutely no idea
    they exist and is not contributing at all toward their
    implementation. The only thing the host OS sees is a bunch
    of pages from a file being mapped and unmapped from
    memory.

    In fact, 9vx would probably be easier to bring up on Windows
    than trying to do anything special just to implement rfork
    for a p9p-style port (not implementing rfork would
    be easier still; see below).

    > I have been very slowly crawling towards an updated port of 9pm
    > (p9p for windows as it was) learing the Windows API and the plan9
    > kernel as I go.
    >
    > The one total show stopper is a lack of a real fork() in windows.
    >
    > This meant I chose to implement rfork(RFPROC) as somthing like vfork() -
    > CreateThread() followed by CreateProcess() whilst the parent is blocked.
    > This works in simple cases but breaks on rc(1). This is fixable by
    > modifying the rc source (rc runs under windows in its inferno form anyway)
    > but that is not the point.
    >
    > I implemented rfork(RFPROC|RFMEM) as CreateThread() with stack copy
    > and relocation. This works well but means every windows-thread/plan9-psudo-proc
    > has a different stack and thus _tos and _tos->pid won't work.


    This is a separate issue. In p9p I prepared for this by getting
    rid of all the uses of rfork to create threads, replacing them
    with the thread library and threadcreate. The latter should be
    easier to implement with Windows primitives, if you stay that
    course.

    Russ



  6. Re: [9fans] 9vx fork problem

    >> I think this is at the root of why 9vx cannot run on MS-Windows.

    > No, it's not.


    I can only appologise for emailing before reading the vx30 paper properly,
    I now understand (some of) how cunning it really is.

    I 9vx for windows is the way to go.

    Thanks russ.

    -Steve


  7. Re: [9fans] 9vx fork problem

    Pietro Gagliardi wrote:
    > - Modify the kernel (it is based on Unix - even Microsoft says so)


    Sure it is...in the same way that VMS is based on UNIX (which means not
    at all....)


+ Reply to Thread