Date: Fri, 19 May 2023 00:40:21 +0000 From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 271490] Deadlock between _rtld_atfork_pre and _thr_attr_init Message-ID: <bug-271490-13406-HlEUXsDfLf@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-271490-13406@https.bugs.freebsd.org/bugzilla/> References: <bug-271490-13406@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271490 --- Comment #2 from KJ Tsanaktsidis <kj@kjtsanaktsidis.id.au> --- Thanks for your quick eyes. > It seems that the problem is that malloc_mutex_prefork() from jemalloc/src/mutex.c does not lock _all_ jemall= oc mutexes, in particular, the extent mtx. I guess I could try patching this and see if it makes the deadlocks on my machine go away. I'll give it a go over the weekend and report back! > OTOH, note that after fork(), in multi-threaded process child, only async= -signal safe functions are guaranteed to work. Yeah.... this is unfortunately very common in the Ruby world though, becaus= e of a combination of two things: * Gems (especially gems by monitoring providers like Datadog, Sentry, NewRe= lic, etc) that maintain background threads (to e.g. report metrics & exceptions asynchronously to some central service) * Pre-forking webservers (like Unicorn) are frequently used to get good use= of multi-core machines (since only one Ruby thread can run Ruby code at a time= ). These webservers often load all of an applications gems, and _then_ fork workers, to get good use of shared copy-on-write pages. Most gems that maintain background threads install after_fork hooks to rest= art them when they're used inside preforking webservers. The documentation for fork(2) does say: > The FreeBSD implementation of fork() provides a usable malloc(3), and rtl= d(1) services in the child process. when referring to multi-threaded forks, so I guess _this_ is supposed to wo= rk. I do note however that the man page says nothing about DNS resolution worki= ng in the child of a multithreaded fork :/ but that's a problem for another day (maybe Ruby ensures that the resolver is not in use before forking? I haven= 't looked) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-271490-13406-HlEUXsDfLf>