From: Eric Wong Date: 2017-12-25T23:37:26+00:00 Subject: [ruby-core:84448] Re: [Ruby trunk Misc#14222] Mutex.lock is not safe inside signal handler: what is? shatrov@me.com wrote: > normalperson (Eric Wong) wrote: > > In fact, it is never safe to > > use locking such as `pthread_mutex_lock` inside a signal handler. > > Do you think it's likely that your work towards Mutex that > does not rely on threads (r13517) would allow us to use Ruby > Mutex from a signal trap? As far as I understand, that would > mean getting rid of `pthread_mutex_lock` on CRuby. No, the principle for the mutex rewrite [Feature #13517] is the same as any other simple (fast) mutex implementation, so the same caveats apply(*). I think what you're looking for is a reentrant (or recursive) mutex. I haven't looked into those in many years; but from what I recall, they were generally discouraged for being tricky to use. Not speaking for matz and ko1, but I recall them not liking Mutexes in the language. So reentrant mutexes would probably not be welcome. (*) The work done on Mutex was to make them more sympathetic to the current VM and GVL by removing redundancies. It still relies on the GVL (which uses pthread_mutex_lock), and the implementation will need to evolve as the VM evolves. One side-effect of those changes is the current iteration can be easily ported for use with green threads (Thriber) in case that feature is accepted. Unsubscribe: