Make y-rb thread-safe

[eliias]

Problem

y-rb is not thread-safe. Originally I thought there are no use cases where concurrency patterns need to be supported, but it is relatively easy to shoot yourself into the foot when using y-rb with ActionCable in Rails. In particular, the combination of update events (attach(…)) with worker pools cause some issues (I get segfaults here and then).

To do

• Set up a test case that somewhat deterministically fails within a multithreaded environment
• Evaluate blocking transaction usage with one of the primitives from https://github.com/ruby-concurrency/concurrent-ruby

[jpcamara]

@eliias do you have a good example of this in practice? Is it a Y::Doc actually shared between threads, or is it just using yrb in a threaded environment at all, even if not shared across threads?

[eliias]

@eliias do you have a good example of this in practice? Is it a Y::Doc actually shared between threads, or is it just using yrb in a threaded environment at all, even if not shared across threads?

IIRC I observed these issues while working on the ActionCable implementation. I can't quite remember the details, but my theory was that Websockets/SSE are all handled from a dedicated thread pool per puma process, and that my implementation simply allows any thread to interact with the doc. e.g., any sync callback might execute on any thread, and is capable of mutating the doc without any concurrency control (no locks, etc.).

Scratch that, I think this isn't the issue. From what I understand, ActionCable never shares state across threads (per channel/connection instance). I honestly can't remember.