[DougBarth]

If I'm reading this proposal correctly, locks will still be needed within multithreaded guilds to guard mutations against complex object graphs.

Here's my reasoning. Since the GVL is insufficient to guard against data races on Ruby 2, under the guild system, locks would be needed to guard against concurrency issues if multiple threads are present.

It would seem like the intention would be to replace usages of Thread with Guild to avoid the concurrency issues inherent with threaded code. Will there be API support to create a Guild that only allows a single thread?

[dragonwriter]

> locks will still be needed within multithreaded guilds

It seems to me that is the intent; that is, any Ruby code that exists now is single-guild Ruby 3 code -- if its multithreaded, it needs locks, for the same reason it does now.

> It would seem like the intention would be to replace usages of Thread with Guild to avoid the concurrency issues inherent with threaded code

I think that'll be a common use case, though running what amount to multiple "legacy" Ruby 2 multithreaded systems in separate Guilds in the same Ruby 3 process seems also to be an intended supported use case.

> Will there be API support to create a Guild that only allows a single thread?

It certainly sounds like a good idea.

[nateberkopec]

> If I'm reading this proposal correctly, locks will still be needed within multithreaded guilds to guard mutations against complex object graphs.

That is correct. You'll still need to use locks if doing multi-threading inside of Guilds.

It looks like Guilds can have 1 to X threads.