Date: Fri, 24 Aug 2018 22:23:15 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Eric van Gyzen <eric@vangyzen.net> Cc: Gleb Popov <6yearold@gmail.com>, freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Strange hang when calling signal() Message-ID: <20180824192315.GF2340@kib.kiev.ua> In-Reply-To: <4e555da7-9384-0f22-3ef9-8b3661a48529@vangyzen.net> References: <CALH631mtb1Z-4v4%2BUuzCx0tX0Zt5LfoQR9%2Biags-nL7MRUhGLA@mail.gmail.com> <20180824185328.GE2340@kib.kiev.ua> <4e555da7-9384-0f22-3ef9-8b3661a48529@vangyzen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 24, 2018 at 02:10:36PM -0500, Eric van Gyzen wrote: > On 8/24/18 1:53 PM, Konstantin Belousov wrote: > > Since then, we started locking most of that locks in parent around fork(2), > > all the code in lib/libthr/thread/thr_fork.c. In particular, we lock rtld, > > malloc, and disable cancellation around fork. So if your program used fork(2) > > but ended with the broken rtld it is worrying. > > > > On the other hand, we do not do that for vfork(2). So yes, the minimal > > We also do not do that for rfork(2). I think we should, but I have not > done any research into it. I do not see how would it be correct to do that locking for vfork(2) because the address space is shared between parent and child. For the similar reason, sometimes rfork(2) also leaves the address space shared and then we have the problem. In essence, rfork(2) and vfork(2) do not mix with pthreads, and if you do, you should know well what you do.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180824192315.GF2340>