http://9fans.net/archive/1999/07/119fans archive / 1999 / 07 / 11 / prev next From: Digby Tarvin [EMAIL PROTECTED] Subject: [9fans] spawn() vs fork() Date: Mon, 5 Jul 1999 14:23:27 +0100 (GMT/BST) > >> 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 [EMAIL PROTECTED] http://www.cthulhu.dircon.co.uk |
