Messages in this thread | | | Date | Fri, 8 Jan 1999 16:33:55 -0500 (EST) | From | Kenneth Albanowski <> | Subject | Re: Porting vfork() |
| |
On Fri, 8 Jan 1999, Linus Torvalds wrote:
> > 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/
| |