Date: Thu, 22 Jan 2009 02:44:37 -0500 From: David Schultz <das@FreeBSD.ORG> To: Daniel Eischen <deischen@FreeBSD.ORG>, hackers@FreeBSD.ORG, Jason Evans <jasone@FreeBSD.ORG>, Julian Elischer <julian@elischer.org> Subject: Re: threaded, forked, rethreaded processes will deadlock Message-ID: <20090122074437.GA61965@zim.MIT.EDU> In-Reply-To: <20090122071703.GA61697@zim.MIT.EDU> References: <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> <20090120004135.GB12007@green.homeunix.org> <20090121230033.GC12007@green.homeunix.org> <Pine.GSO.4.64.0901211831210.4150@sea.ntplx.net> <20090122045637.GA61058@zim.MIT.EDU> <Pine.GSO.4.64.0901220021320.4150@sea.ntplx.net> <20090122071703.GA61697@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 22, 2009, David Schultz wrote: > If you can't implement functions that are required to be > async-signal-safe like fork() and exec() without malloc(), then > for now I guess we should go for something along the lines of what > Brian is proposing. If the app programmer has taken special pains > to ensure that all other threads are stopped when a fork happens, > the fork() call shouldn't return in the child with all the malloc > locks bogusly held. Note that even with Brian's patch, the memory associated with the all the parent's threads' stacks is leaked, and libthr can't be expected to be in a particularly happy state after all of its threads disappear. It just happens to (sort of) work for now. In any case, it's clearly a bug that libthr's fork handler calls _malloc_postfork() in the child even when _malloc_postfork() doesn't work properly in the (now single-threaded) child. Which way to fix it is up to you guys...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090122074437.GA61965>