[#103241] [Ruby master Bug#17777] 2.6.7 fails to build on macOS: implicit declaration of function 'rb_native_mutex_destroy' is invalid in C99 — eregontp@...
Issue #17777 has been reported by Eregon (Benoit Daloze).
17 messages
2021/04/05
[#103305] [Ruby master Feature#17785] Allow named parameters to be keywords — marcandre-ruby-core@...
Issue #17785 has been reported by marcandre (Marc-Andre Lafortune).
21 messages
2021/04/08
[#103342] [Ruby master Feature#17790] Have a way to clear a String without resetting its capacity — jean.boussier@...
Issue #17790 has been reported by byroot (Jean Boussier).
14 messages
2021/04/09
[#103388] [ANN] Multi-factor Authentication of bugs.ruby-lang.org — SHIBATA Hiroshi <hsbt@...>
Hello,
5 messages
2021/04/12
[#103414] Re: [ANN] Multi-factor Authentication of bugs.ruby-lang.org
— Martin J. Dürst <duerst@...>
2021/04/13
Is there a way to use this multi-factor authentication for (like me)
[#103547] List of CI sites to check — Martin J. Dürst <duerst@...>
Hello everybody,
4 messages
2021/04/22
[#103596] [Ruby master Feature#17830] Add Integer#previous and Integer#prev — rafasoaresms@...
Issue #17830 has been reported by rafasoares (Rafael Soares).
9 messages
2021/04/26
[ruby-core:103618] [Ruby master Bug#17827] Monitor is not fiber safe
From:
eregontp@...
Date:
2021-04-27 16:53:03 UTC
List:
ruby-core #103618
Issue #17827 has been updated by Eregon (Benoit Daloze).
Fixed in https://github.com/ruby/ruby/commit/3a3b19b2bba49e5d6f1cf13764eb6dd701397be9.
This should be backported to 3.0 (I marked it as such).
I noticed something else while writing a test for this:
On 2.7:
```
ruby -e 'm=Mutex.new; m.lock; p 1; Fiber.new { m.lock }.resume'
1
Traceback (most recent call last):
1: from -e:1:in `block in <main>'
-e:1:in `lock': deadlock; recursive locking (ThreadError)
```
On 3.0:
```
$ ruby -e 'm=Mutex.new; m.lock; p 1; Fiber.new { m.lock }.resume'
1
-e:1:in `lock': No live threads left. Deadlock? (fatal)
1 threads, 1 sleeps current:0x000000000214f080 main thread:0x000000000214f080
* #<Thread:0x00000000021bb488 sleep_forever>
rb_thread_t:0x000000000214f080 native:0x00007f05edc32b80 int:0
from -e:1:in `block in <main>'
$ ruby -e 'Thread.new {sleep}; sleep 0.1; m=Mutex.new; m.lock; p 1; Fiber.new { m.lock }.resume'
1
=> hangs
```
Same behavior on master for `Monitor.new` with my fix (`ruby -rmonitor -e 'm=Monitor.new; m.enter; p 1; Fiber.new { p m.enter }.resume'` => fatal, or hang if there is another Thread).
It would be nice to raise a ThreadError when detecting in Mutex#lock that the Mutex is owned by the same Thread but a different Fiber, if there is no Fiber scheduler.
That's more of a nice-to-have though.
----------------------------------------
Bug #17827: Monitor is not fiber safe
https://bugs.ruby-lang.org/issues/17827#change-91715
* Author: ioquatix (Samuel Williams)
* Status: Closed
* Priority: Normal
* Assignee: Eregon (Benoit Daloze)
* Backport: 2.6: DONTNEED, 2.7: DONTNEED, 3.0: REQUIRED
----------------------------------------
According to our discussion here https://github.com/rspec/rspec-support/issues/501 it seems like typical implementation of per-thread reentrant mutex is no longer valid and can lead to some deadlock situation.
```
#!/usr/bin/env ruby
require 'monitor'
def monitor_failure
m = Monitor.new
f1 = Fiber.new do
m.synchronize do
puts "f1 A"
Fiber.yield
puts "f1 B"
end
end
f2 = Fiber.new do
m.synchronize do
puts "f2 A"
# Fiber.yield
f1.resume
puts "f2 B"
end
end
f1.resume
f2.resume
end
monitor_failure
```
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>