On 08/07/2014 05:51 AM, Ken Brown wrote: > > I think I found the problem with NORMAL mutexes. emacs calls > pthread_atfork after initializing the mutexes, and the resulting > 'prepare' handler locks the mutexes. (The parent and child handlers > unlock them.) So when emacs calls fork, the mutexes are locked, and > shortly thereafter the Cygwin DLL calls calloc, leading to a deadlock. > Here's a gdb backtrace showing the sequence of calls:
Arguably, that's an upstream bug in emacs. POSIX has declared pthread_atfork to be fundamentally useless; it is broken by design, because you cannot use it for anything that is not async-signal-safe without risking deadlock. And (except for sem_post()), NONE of the standardized locking functions are async-signal-safe. http://austingroupbugs.net/view.php?id=858 That said, it would still be nice to support this, since even though the theory says it is broken, there are still lots of (broken) programs/libraries still trying to use it. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
