>> First it assumes that the image you want to load is still
>> on disk but that it's not necessarily true... it might be deleted or
>> replaced with a new version.
>>
>> Second, doing a load_image() will discard any changes you have
>> done to the current data segments.
>
>I'm always interested as the next guy in getting bogged down in the details
>and completely off track, but I thought we were talking about :
>
>pid_t fork(void)
>
>All it does is create a duplicate process (runs the same program),
>as a separate process with it's own variable space. There's no real
>magic there.
This is true enough.
>As for missing programs etc., personally when I run an application
>I don't tend to delete the executable file while things are in progress.
But it could happen. No, you don't do that. But the semantics of fork
allow for it. Not to mention self-modifying code. Yeah, I know that
is considered to be a BAD thing. But people do it. And fork has to support
it. :-/
>In the case of stacks, a true fork function is, by definition, creating
>a separate process with its own dataspace. Why would I care where
>the stack for a new process is placed, as long as the new process can
>use it?
Simple answer - because fork inherits the stack from the parent.
This should work:
int foo;
int pid;
foo=9;
pid=fork();
if (!pid)
{
printf ("%d\n",foo);
}
And, though I didn't show it here, addresses can be placed on the stack, and/or
registers could have addresses that point into the stack. That must continue to
be valid.
>>Sixth, did i mention signal handlers?
>
>You're assuming that a posix library needs to
>use BeOS signals for this. At its core it probably will.
>However, there is nothing that stops the fork()
>routine from doing a bit of reorganization, or
>from having it's own separate signal queue,
>(ie: posix engine) if you really want to go that far.
> Just having fork() spawn a separate process
>that can be 'zombied' is O.K. for a first kick at the
>can. I've never seen a posix program use it for
>anything more extensive than this anyway.
>(ie: incoming http request, spawn a new job on port ####,
>ok, done, go back to listening on port 80)
While this is true (that the use of fork seems limited),
there may be many more cases where the compiler is doing
"stuff" under the hood.