Date: Fri, 9 Jan 2009 10:36:44 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Brian Fundakowski Feldman <green@freebsd.org> Cc: hackers@freebsd.org, jasone@freebsd.org Subject: Re: threaded, forked, rethreaded processes will deadlock Message-ID: <Pine.GSO.4.64.0901091034310.1234@sea.ntplx.net> In-Reply-To: <20090109053117.GB2825@green.homeunix.org> References: <20090109031942.GA2825@green.homeunix.org> <Pine.GSO.4.64.0901082237001.28531@sea.ntplx.net> <20090109053117.GB2825@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 9 Jan 2009, Brian Fundakowski Feldman wrote: > On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: >> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: >> >>> It appears that the post-fork hooks for malloc(3) are somewhat broken such that >>> when a threaded program forks, and then its child attempts to go threaded, it >>> deadlocks because it already appears to have locks held. I am not familiar >>> enough with the current libthr/libc/rtld-elf interaction that I've been able >>> to fix it myself, unfortunately. >> >> There's really nothing to fix - according to POSIX you are only >> allowed to call async-signal-safe functions in the child forked >> from a threaded process. If you are trying to do anything other >> than that, it may or may not work on FreeBSD, but it is not >> guaranteed and is not portable. >> >> The rationale is that what is the point of forking and creating >> more threads, when you can just as easily create more threads in >> the parent without forking? The only reason to fork from a threaded >> process is to call one of the exec() functions. > > Well, it worked until the last major set of changes to malloc. For me, the point > was that I was able to have transparent background worker threads in any program > regardless of its architecture, using the standard pthread fork hooks. Could you > point me to the POSIX section covering fork and threads? If it's really not > supposed to work then that's fine, but there's an awful lot of code there dedicated > to support going threaded again after a fork. I don't know if this link will work for you, but you can start here: http://www.opengroup.org/onlinepubs/009695399/nframe.html "It is suggested that programs that use fork() call an exec function very soon afterwards in the child process, thus resetting all states. In the meantime, only a short list of async-signal-safe library routines are promised to be available." -- DE --
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0901091034310.1234>