[9fans] spawn() vs fork()

[9fans] spawn() vs fork()

[rog]

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

inferno seems to do fine with a spawn primitive and no process
fork. it has the capability to fork resources (i.e. fds, namespace,
process group) and this, combined with the fact that there are
relatively few attributes associated with a process, seems quite
sufficient for all the usual process setup.

  cheers,
    rog.

[9fans] spawn() vs fork()

[Digby]

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

[9fans] spawn() vs fork()

[steve.kilbane]

On 03/07/99 16:22:21 Digby Tarvin  wrote:

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

steve

[9fans] spawn() vs fork()

[Digby]

>
>Imagine how you would do IO redirection with spawn().
>
I don't have to imagine - I have done a lot of work with the OS-9
operating sytem which does just that.

OS-9 dates back to the time when memory management with dynamic
address translation was pretty rare and exotic (originally ran
on M6809) so for maximum hardware portability the system
assumes that everything works on physical addresses.
MMU, if available, is only used to restrict read/write access.

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.

I/O redirection is implemented using a flurry of dup(), close() open()
calls before and after the child is created (combined with the ability
to control how many open file descriptors are passed on to the child).

Fork() is a much more elegant way of giving code in the parent
process a chance to initialise the environment for the child
before transferring control - not only I/O, but also current
directory, UID, priority etc, all without having to define a
set of additional system calls or adding a long list of arguments
to the spawn request...

On the down side, appart from relying on address translation, fork()
is usually more complex to implement in the kernel, and a
fork()/exec() sequence usually involves more run time overhead
than a single combined semantic.

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

[9fans] spawn() vs fork()

[Jean]

Imagine how you would do IO redirection with spawn().

jm

[9fans] spawn() vs fork()

[Guan]

Hi

What are the advantages of fork() vs spawn() for system()-like uses? I
couldn't find this in comp.os.research FAQ.

>From an application programmer's point of view spawn() would be much
easier to use, except when creating two processes or threads that do
exactly the same thing.

--
The nice thing about Windows is - It does not just crash, it displays
a dialog box and lets you press 'OK' first.

Read this at www.geekcode.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d- s-:+ a---- C++ UL++ P+ L++ E- W++ N o K- w--- O M- V-- PS+ PE+ Y+
PGP+ t+ 5- X++ R+ tv b+++ DI+ D+ G e-- h! !r !z
------END GEEK CODE BLOCK------