Re: [9fans] 9vx fork problem

[Pietro Gagliardi <pietro10@mac.com>]

- 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
>