continulet stacks on the heap and other schemes for io/threading
Hi, over the last few weeks few ideas have been brooding in the back of my head, in particular after seeing how rust creates its stacks and handles io. The basis is allocating all stacks as non-movable structures on the heap. This would remove the need to copy the c/rpython level stack for continulets and enable to move them between native threads which is essentially enabling a M:N threading scheme. On top of that i would like to introduce transformation similar to the sandbox that would defer all IO to a io loop in a separate thread. Additionally it should change the threading abstractions to use said continuation instead of os level threads the result in case of a success would be a python that defers all blocking operations to a io loop in a separate thread im currently investigating libuv, since it does well for async io and also has utilities to defer blocking calls to c code to a pool of native threads -- Ronny
On Tue, Feb 26, 2013 at 4:29 PM, Ronny Pfannschmidt
Hi,
over the last few weeks few ideas have been brooding in the back of my head, in particular after seeing how rust creates its stacks and handles io.
The basis is allocating all stacks as non-movable structures on the heap.
This is essentially done on jitframe-on-heap (as the name suggests) for the JIT.
Hi,
On Tue, Feb 26, 2013 at 4:08 PM, Maciej Fijalkowski
The basis is allocating all stacks as non-movable structures on the heap.
This is essentially done on jitframe-on-heap (as the name suggests) for the JIT.
I think that what Ronny has in mind is different. Unless I'm mistaking it, Rust's "tasks" are green threads, but still thread-like structures, but fully managed by the process. They each have their own C-level stack. That's why you can run 100'000 of them in maybe 1 GB of RAM (rough order of magnitude), but not 1 or 10 million of them. CPython's Stackless and PyPy's stacklets allow basically one order of magnitude more. For PyPy as well as "hard-switching" Stackless this comes at the cost of needing to do copies around. I suppose it's a trade-off between this cost and the extra memory of green threads, so I cannot judge a priori which solution is the best --- it probably depends on the use case. The jitframe-on-heap branch "just" enables, finally, PyPy's existing coroutines to be fully JITted. A bientôt, Armin.
participants (3)
-
Armin Rigo -
Maciej Fijalkowski -
Ronny Pfannschmidt