[#84867] [Ruby trunk Bug#14357] thread_safe tests suite segfaults — v.ondruch@...

Issue #14357 has been reported by vo.x (Vit Ondruch).

11 messages 2018/01/15

[#84980] [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — hsbt@...

Issue #13618 has been updated by hsbt (Hiroshi SHIBATA).

10 messages 2018/01/23
[#85012] Re: [Ruby trunk Feature#13618][Assigned] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — Eric Wong <normalperson@...> 2018/01/23

hsbt@ruby-lang.org wrote:

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

From: Eric Wong <normalperson@...>
Date: 2018-01-27 09:39:41 UTC
List: ruby-core #85155
eregontp@gmail.com wrote:
> I think that would be very helpful and help to discuss possible improvements.
> Also explaining why Mutex is problematic (the signal handler can be run between any 2 lines of code, and Mutex is not re-entrant).
> Can I assign this to you to create the document?

Sure; quite a bit of work and yes, I'm noticing some ickiness
along the way...


Ugh, I still hate how big rb_io_t is and the presence of write_lock +
rb_mutex_allow_trap does not make me comfortable(*) :<
(Fortunately pipes and sockets default to IO#sync=true)

I know some code uses Mutex#synchronize to cover a huge scope
nowadays, but maybe disabling Signal.trap blocks from firing
while any Mutex is locked gets rid of a huge chunk of problems
(at the expensive of new ones)

Or we could've had lock-free operations from the start and never
had a Mutex class in the first place :>

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread