tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: inheriting the lwp private area

On Wed, Mar 23, 2011 at 12:53:24AM -0700, Matt Thomas wrote:
> On Mar 22, 2011, at 8:51 PM, Antti Kantee wrote:
> > Hi,
> > 
> > On Julio's request I was looking at the now-failing tests and resulting
> > hanging processes.  Basically at least on i386 the failures are a
> > result of fork() + setcontext() (plus some voodoo) after which calling
> > pthread_mutex_lock() with signals masked causes a busyloop due to
> > pthread__self() causing a segv but the signal never getting delivered
> > (that in itself seems like stinky business, but not the motivating factor
> > of this mail).
> > 
> > Per 4am intuition it seems pretty obvious that a child should inherit
> > the forking lwp's private data.  Does that make sense to everyone else?
> > At least patching fork1() to do so fixes the hanging processes and
> > failing tests and a quick roll around qemu hasn't caused any problems.
> > 
> > If it doesn't make sense, I'll disable the pthread bits (per commit
> > guideline clause 5) until support is fully fixed so that others don't have
> > to suffer from untested half-baked commits causing juju hangs and crashes.
> You mean l->l_private should be copied on fork?  Absolutely.

For native fork I agree, but that's probably not the right thing to do if
FORK_SHARESIGS or whatever it's called (i.e. clone()ing off a Linux-style

(Some day I hope we can emulate clone with _lwp_create() and undo a lot of
the complication to the process data structures.)

Home | Main Index | Thread Index | Old Index