> Wrong again. > > 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. 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. 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? >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) If your main server program crashes or its program disappears, assuming this takes down all your threads of execution, you have more serious problems than forking. >We all make fun out of unix at some time, but that's no excuse >for calling "eunucs" to people who actually like it. You're kidding me right? Lighten up. It's a string of binary digits. In 100 years who will care? Peter