lkml.org 
[lkml]   [1999]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Porting vfork()
Date
> > 
> > Yep, separate wait queue for each instance, child notifies parent, everything
> > is happy.
>
> Make sure that the parent hasn't gone away in the meanwhile.

When it is an issue (before exec/exit) it's still considered a cloned thread and
the parent can't go away without the child going away too.

>
> > That's a good question, do you want to temporarily block signals to the parent?
>
> I'm not sure, and I'm not sure what traditional behaviour is for this.
> Letting the parent execute a signal handler is pretty clearly wrong, so I
> guess signals have to be blocked for the duration. What about SIGKILL? I
> guess leave it unblocked, otherwise we could have an unkillable parent.
> That means the parent could go away while the child is still running, so
> make sure the child won't die if this happens.

If I read the code right, see above, the parent can't go away while the child is
dependent on it because the mm structure is shared beteen them.

>
> > The patch that I sent out (it's gonna hit the list sometime) bypasses the
> > obvious problems of sharing VMs, by simply recognizing that in an MT app,
> > your VM area WILL be modified, irregardless. For ST apps, you just have
> > the parent go to sleep.
>
> Sorry, I didn't follow that. My assumption is that MT will work
> identically to ST: the thread that invokes vfork() will go to sleep until
> its child execs or exits. No other special behaviour is required. No
> threads other then the one that vfork()'d will be affected.

Correct, I'm just ignore the fact that the VM will change underneath the thread's
child, it's immaterial because it's a threading issue, hence it's an app programmer
issue.

>
> This behaviour seems to be required, due to the meaning of vfork(): the
> parent and child share the stack, so they cannot both execute at the same
> time (hence the wait_queue). Separate threads do not share the stack
> (never mind that they share everything else), so each thread can use
> vfork() independantly and safely.

Since a vforked child is the same as a cloned thread, the stack should get cloned
too, I think.

>
> >
> > Well, I think it'll happen, my patch it out (I have a new rev in my tree which
> > adds the syscall to unistd and fixes the p_pptr thing to p_opptr).
> >
> > I'm doing this because I'd like to see someone use the new vfork to write a better
> > FTP server for Linux, not to mention that Apache could benefit CGI wise.
>
> 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.

It's the same as clone, it just blocks the parent. It's this semantic which makes
it better; when the parent wakes up, it can do the wait on the child and wake up in
the same context, avoiding a superfluous context switch, because the data is immediately
available.

>
> Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
>

--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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [from the cache]
©2003-2011 Jasper Spaans