> > Make sure that the parent hasn't gone away in the meanwhile.
>
> It cannot - even if the parent goes away, p_pptr will just point to
> another valid parent (ie init) instead. So it should always be safe to do
> a "wakeup(¤t->p_opptr->sleep)"
Ah, I see, this being how init "inherits" tasks that lose their parent.
Very clean.
> > Actually I'd be surprised if this vfork() would gain you anything on a
> > normal system: I don't see how it's particularly better then clone(). As I
> > said, I'm concerned with systems where fork() isn't feasible.
>
> vfork() is a lot easier to use than clone() (you don't need to know about
> threading, because everything is basically single-threaded as far as the
> application is concerned - the only entity that needs to know about
> vfork() is basically the compiler, because vfork() has setjmp() like
> properties when it comes to automatic variables).
Oh, yes, if you just want a fork()/exec(), vfork() is quite pleasent
and safe. I'll just be surprised if anyone uses it for more "advanced"
techniques.
Mind you, unless I've missed something, not only will the setjmp() issues
apply, but a macro will be needed to invoke the vfork syscall in the first
place, lest the child returning from the vfork function tromp on the
parents stack if the child pushes anything before finishing.
> Also, there are actually old programs there that use vfork() already, so
> you get some of it completely for free, without having to rewrite them to
> use a Linux-specific clone()..
Yes, my thought exactly. Linux has always been good about supporting
interfaces both ancient and modern, and it wouldn't hurt to have this one
available.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/