Messages in this thread | | | From | Perry Harrington <> | Subject | Re: Porting vfork() | Date | Thu, 7 Jan 1999 22:30:48 -0800 (PST) |
| |
> > Date: Fri, 8 Jan 1999 01:06:58 -0500 (EST) > From: Kenneth Albanowski <kjahds@kjahds.com> > > On Thu, 7 Jan 1999, Perry Harrington wrote: > > > I discussed this issue with Linus as well, and concluded that > > vforking within a cloned process can be achieved via putting the > > sleep_on in the task structure. I'm going to be working on this > > tonight and I'll see what I can do. > > I do think a sempahore would be appropriate to avoid the > possibility of recursion. > > Last time I checked BSD doesn't even fully handle the recursive > vfork() case, and thus we should not need to either. Just make sure > the kernel retains it's own internal integrity in such a case, nothing > more.
For the time being I added another wait queue to struct task, and I do a sleep_on in the parent. When the child exits, in do_exit, just after notify_parent, it does a wake_up on current->p_pptr->vfork_sleep.
I think that most of the handling could be eliminated if we simply reused the chldexit queue that wait4 uses. Essentially forking then waiting, but wait it signal interruptable.
The reason I did it the way I did it, is so you could vfork from a cloned thread, and theoretically a recursive vfork should work without error.
I haven't tested it yet, just got all the code in and built a kernel, next I'll write a test proggy.
Just to be clear, I'd need to do a SYS_190() to call it, right? If not, how do you make direct syscalls?
> > Later, > David S. Miller > davem@dm.cobaltmicro.com >
--Perry
-- Perry Harrington Linux rules all OSes. APSoft () email: perry@apsoft.com Think Blue. /\
- 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/
| |