| From: | Patrick Roberts |
| Date: | 8 Aug 2000 at 17:50:14 |
| Subject: | Re: AMIOPEN: ave_open() |
Just to add to your description of what fork() does, and one of the main
reasons I use fork() is that the child and parent process share memory until
one does a write, then only the page that the process writes to is copied and
tracked. This is great for anything wanting to take advantage of multi-proc
set-ups as the performance increase is much faster than using threads. At
least this is how it works in Linux and IRIX.
-Pat
Tim Corringham wrote:
>
> 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
>
> --
> ======================================================================
> Tim Corringham e-mail: tim@ramjam.u-net.com
> Ramjam Consultants Ltd tel: +44 (0)118 946 5940
> Reading, England fax: +44 (0)118 946 5941
>
> Subscribe/Unsubscribe: open-request@amiga.com
> Amiga FAQ: http://www.amiga.com/faq.html
Subscribe/Unsubscribe: open-request@amiga.com
Amiga FAQ: http://www.amiga.com/faq.html