[openbeos] Re: Kernel status (POSIX)
- From: "Manuel Jesus Petit de Gabriel" <freston@xxxxxxxxxxx>
- To: <openbeos@xxxxxxxxxxxxx>
- Date: Sat, 29 Dec 2001 12:51:51 -0800
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,
Other related posts:
