Hi, > void *pitch_fork( /* some parameters */) > { > /* > use some standard beos functions like.... > */ > create_area(); > clone_area(); > delete_area(); > > /* > to share data > */ You may want to create the new team first, as the ???_area() functions operate in the current address space, not in foreign address spaces. But it will be wrong, since clone_area() actually shares an area; it does not create a copy-on-write sibling of the original area. Even if i tell you ca to trick the BeOS kernel into creating COW areas you'll run into some other troubles. > /* > and standard beos functions like.... > */ > load_image(); > > /* > to create new teams; essentially the same as forking > if the process your spawning is identical to the current process > */ 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. Third, load_image() will create an initial thread ready to run at the beginning of the C runtime in order to call main() after some initialization gymnastics. However you want that initial thread to be ready to run at some stub function (that could for instance copu in the modifications in the parent data segement) that will return into the fork() caller. Fourth, you have not think of stack issues the thread in the new team will have (in a lot of cases) the stack placed at a different address than the original thread and this will give you some troubles when trying to returun from fork() in the new team. Fifth, it looks like you have forgotten about file descriptors and CLOEXEC. Any file descriptor marked as CLOEXEC wil be closed in the child team after a load_image() (or after an exec()) however POSIX semantics require them to remain open after a fork(). Sixth, did i mention signal handlers? After a load_image() (or exec() ) all signal handlers that you have defined to something other than SIG_DFL or SIG_IGN will be reset to SIG_IGN, the POSIX semantics require that signal handlers are preserved across forks. So somehow you have to reinstall in the child all the signal handlers the parent had... but beware because a signal can be posted to the child before you have a chance of reinstalling the handlers. And the list of issues to solve is not done, there are still other problems as add-ons and libraries loaded after the team started. > > etc....(); > > return /* a void pointer that the fork function can use */ ;; > /* > posix is gonna get scewered....bet on it... > */ Probably yes, but you need to do better than this example. > > The "eunucs" part is totally uncalled for. > > Sensitive? he he.... Not really, just trying to preserve a sense of correctness. > It's and OS not a religon. I've been using UNIX > since 1982. I think it's safe to say I understand > some of its failings. Enough to be allowed to > make fun of it anyway. We all make fun out of unix at some time, but that's no excuse for calling "eunucs" to people who actually like it. > Wasn't Mike Phipps organizing these things? I think so. Regards, manuel,