Re: [9fans] 9vx fork problem

["Russ Cox" <rsc@swtch.com>]

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