4 ms·
Anyone correct me if I'm wrong here. Seems like a guild is just a subprocess with its own resources. And you copy objects over as needed. And when the guild is
by artellectual 10y ago
Anyone correct me if I'm wrong here.
Seems like a guild is just a subprocess with its own resources. And you copy objects over as needed. And when the guild is done it will get garbage collected. Like other objects.
- Someone 10y agoI think I would consider implementing it as 1:1 threading where every thread=guild runs its own set of green threads. That likely would be faster than having OS threads in each guild that use PS locks to prevent running >1 of them concurrently.
- _ko1 10y agoCRuby/MRI supports C-extension which can use TLS (thread-local-storage). So that each Ruby threads runs on one OS thread.
- the_mitsuhiko 10y ago> Seems like a guild is just a subprocess with its own resources. In an ideal world the guild is the interpreter state which would be very far from processes. How far down you can go there largely depends on what promises the API made to C extensions and other things in the past.
- Roboprog 10y agoThe Guild concept feels much like a mix of actors and messaging from Erlang and Go. Not as restrictive as Erlang, but not as permissive as Go. (there was a nod to Elixir/Erlang in the slides)
- _ko1 10y agoYes. Actually, I think Go is some kind of multi-thraeding (goroutine is only a useful mechanism on the "threads" and can't help to avoid multi-threads difficulties (but this design helps to reduce difficulties)).
- Roboprog 10y agoI would like to thank the team behind this proposal, very much, by the way. I have not tinkered with Ruby in a few years, but this looks like a major breakthrough.
- _ko1 10y agoLike sub-process, but share many things like bytecodes (ISeq in MRI context), class and module objects (and method tables) and so on. Also we can share immutable objects (deeply frozen objects) like threads.