Add locks around accesses/modifications to global encodings table #13600
Conversation
|
Could you add a test and/or reproduction case? Was there a ticket associated with this PR? |
It tends to be difficult to make reliable reproductions to concurrency issues, and at the moment all Ractor tests need an
As Ractors are experimental and there are many issues we aren't necessarily filing tickets as the fixes will not be backported. |
|
Cool just checking, I saw this and thought neat but there was no bug associated or other context, so wasn't sure if it was ready for review or not. 🙏 |
luke-gruber
force-pushed
the
ractor_encoding_add_locks
branch
from
7792937 to
79c7b72
Compare
|
@zzak Sorry yeah, I added a test that is fairly reproducible. |
luke-gruber
force-pushed
the
ractor_encoding_add_locks
branch
2 times, most recently
from
42453db to
463dbb2
Compare
This fixes segfaults and errors of the type "Encoding not found" when
using encoding-related methods and internal encoding c functions across
ractors.
Accessing Encoding#default_external and Encoding#default_internal are
done lock-free (atomics), and accessing one of the 3 main encodings is done
without the VM lock.
Example of a possible segfault in release mode or assertion error in debug mode:
```ruby
rs = []
100.times do
rs << Ractor.new do
"abc".force_encoding(Encoding.list.shuffle.first)
end
end
while rs.any?
r, obj = Ractor.select(*rs)
rs.delete(r)
end
```
luke-gruber
force-pushed
the
ractor_encoding_add_locks
branch
from
463dbb2 to
7311646
Compare
This comment has been minimized.
This comment has been minimized.
luke-gruber
force-pushed
the
ractor_encoding_add_locks
branch
from
4c02b96 to
cffea2b
Compare
This fixes segfaults and errors of the type "Encoding not found" when using encoding-related methods and internal encoding c functions across ractors.