[ruby-core:84448] Re: [Ruby trunk Misc#14222] Mutex.lock is not safe inside signal handler: what is?

[e-mail] 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: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>