[9fans] spawn() vs fork()

[Digby Tarvin digbyt@acm.org]

>
>> That compromise meant that a fork() style of process creation
>> was not possible (all pointers in the child's data segment would
>> be pointing into the parents memory), so it uses a spawn() style
>> of process creation.
>
>It's not impossible: the Atari ST port of Minix managed fork() on M68000. I
>believe the solution was to swap data and stack segments during a context
>switch. This meant that anything that forked a child and then talked to it for a
>while would run like treacle. Since most processes followed a fork() with an
>exec(), it wasn't so much of a problem. All very reminiscent of vfork().
>
>Implementation requirements aside, as Jean says, fork gives you an elegant way
>of setting up I/O redirection. It also gives you an elegant way of determining
>start-up context as a whole for the new process., including internal state.
>
True. I believe Whitesmiths did something similar with a non-mmu
version of their Unix re-implementation.

But OS-9 is intended as a real-time operating system with an ability
to garnatee minimum task switch times. If you are
unwilling to enable the MMU because of the small performance hit that
produces, you certainly wouldn't want to start copying blocks of memory
around as part of task switch overhead...

I have, as a porting aid, implemented a fork() system call
on OS9. But it is not semantically identical to Unix in that
the data segment was shared between parent and child, and the
data changed by the child would effect the data of the parent.
Sort of a vfork() without the copy on write.
But it worked for most fork()/exec() sequences that commonly appear
in Unix source.

Regards,
DigbyT
--
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk