_ko1

4 ms·

1.
by _ko1 10y ago
> Koichi: I do think so. This is mistake. I said "I don't think so". 30% is not enough.
2.
by _ko1 10y ago
More correctly, making a OS thread per a Ruby thread, and creating a Guild makes 1 Ruby thread.
3.
by _ko1 10y ago
Yes. 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)).
4.
by _ko1 10y ago
Because of current limitation. We'll improve it.
5.
by _ko1 10y ago
Yes.
6.
by _ko1 10y ago
absolutely.
7.
by _ko1 10y ago
> Thus, you would have to traverse the entire linked data structure to transfer ownership of every node. This is O(n) work. Correct. > Making things worse, you would have to make sure that the ownership transfer is atomic - no other p
8.
by _ko1 10y ago
So we need to rewrite to support multi-guilds application.
9.
by _ko1 10y ago
Like 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.
10.
by _ko1 10y ago
CRuby/MRI supports C-extension which can use TLS (thread-local-storage). So that each Ruby threads runs on one OS thread.
11.
by _ko1 10y ago
Similar to Erlang process, but more heavy weight (because it creates OS thread per Guild).
12.
by _ko1 10y ago
Yes.
13.
by _ko1 10y ago
Quoted from slides: > GC/Heap > * Share it. Do stop the world parallel marking- and lazy concurrent sweeping. > * Synchronize only at page acquire timing. No any synchronization at creation time.
14.
by _ko1 10y ago
It's magic of transferring membership. I omitted details on slides.
15.
by _ko1 10y ago
Could you link to http://www.atdot.net/~ko1/activities/2016_rubykaigi.pdf ? current one is on temporary file space (will be removed soon).