| From: | Tim Corringham |
| Date: | 8 Aug 2000 at 16:10:12 |
| Subject: | Re: AMIOPEN: ave_open() |
Hi Aaron
> There is no fork(). You must use ixemul_exec() instead which allows
> you to create a child process with given arguments, env variables and
> IO redirection (that's what fork() is "abused" for in most Unix software
> :-( ). I don't know enough about Ami but since Ami has no MP, I guess
> there is no way to make fork() work (for fork(), you must have a way
> to stop a program when it writes to memory, otherwise two processes will
> change the same memory -> chaos).
>
I think it's about time there was a brief overview of fork().
In Unix systems fork() is the *only* way for a new process to be created.
There is no abuse of fork() when creating child processes, that's just
how it is done.
It does this by making an exact copy of the parent process. The parent
process and the child process both continue execution from the point
of the fork() call. The only difference in the execution of the two
is the return value from the fork() call.
In order to make a copy of the parent, the executable code, the stack,
the environment, and the data areas are "copied". The exact mechanism
used to perform the copy isn't important and varies between unix
implementations.
Memory protection isn't required. However a means of making program
execution independent of physical memory address is. This can be VM,
segmented addressing, an indirect addressing scheme (where the offset
of the start of the program is stored in an index register), or some
other scheme.
Now, often when a fork() is performed, the intention isn't to end up
with two identical processes running, but to replace the child process
with some other program and execute it by a call to exec(). Since
copying the program, data, page tables etc is a waste of time if you're
immediately going to discard them, a variant of fork() is available
on many systems which doesn't actually perform the copy - vfork().
This assumes the child will immediately call exec(), and trouble is
likely if it doesn't!
Now, I can't say a lot about Ami as I don't know much about it. However,
I suspect fork is difficult to implement for the same reasons as on
AmigaOS.
1) the flat memory model makes it very difficult to copy executable code
as copying the code to another address will be likely to result in
incorrect execution.
2) the lack of resource tracking makes it difficult to copy data, stack,
etc.
3) Even if copying the data is possible, references to it from the code
are probably invalid due to the changes in the addresses.
Now, even on AmigaOS, a vfork() is possible. For many applications that
is sufficient. I suspect that vfork() could be made to work just fine
on Ami.
Tim
Subscribe/Unsubscribe: open-request@amiga.com
Amiga FAQ: http://www.amiga.com/faq.html