Granian talk @ PyConIT 23

[gi0baro]

You can watch the talk on the Python Italia youtube channel (eng)

[codingmstr]

Hello Giovanni,

First, thank you for your incredible work on Granian.
I’m studying its internals deeply and I have one question regarding the design direction of RSGI:

Why doesn’t RSGI adopt a zero-copy pointer-view protocol?

Specifically:

Passing the request body & headers to Python via a raw pointer (usize),

Letting Python create memoryview objects pointing directly to Rust memory,

Avoiding any copies between Rust → Python,

Using sub-interpreters (Python 3.14) to achieve true parallel execution per-core.

This approach can theoretically remove all overhead:

No bytes copying

No intermediate buffers

No body collectors

No RSGI-level wrapper transformations

I’m wondering if there is a specific limitation or design goal that prevented adopting this direction (e.g., Python C-extensions compatibility, safety concerns, memory isolation between interpreters, or PyO3 limitations).

I’d appreciate your thoughts — especially because I’m exploring building a new ultra-low-latency protocol for high-throughput workloads.

Thanks again for your amazing work.

[gi0baro]

safety concerns, memory isolation

Definitely this.
Passing "pointers" to CPython would involve a lot of unsafe code, and you can't really use lifetimes, which kinda defeats the purpose/advantage of using Rust. Managing GC manually, or even worse, mixing a manual approach while interacting with CPython GC sounds like a nightmare to me.

Using sub-interpreters (Python 3.14) to achieve true parallel execution per-core.

Not sure what this has to do with everything else.

[codingmstr]

Thanks for your reply, Giovanni — let me clarify the architecture I’m referring to.

I’m not proposing passing PyObjects or any Python-managed memory across interpreters.
I’m proposing passing Rust-owned memory only, with Python receiving a memoryview that references a raw pointer owned and lifetime-managed by Rust.

In this design:

Rust owns the buffer (Vec / Arena / Slab).

Lifetime is entirely controlled by Rust, not CPython.

Python never frees or reallocates the memory — only views it.

No GC interaction at all.

No aliasing between interpreters because each interpreter receives only a pointer + length, not a PyObject.

This allows:

Zero-copy request bodies

Zero-copy headers

Zero-copy response building

True parallel execution because each interpreter has its own GIL

No cross-interpreter PyObject passing (avoiding crashes)

So the pointer is not a Python pointer; it’s Rust memory with explicit lifetime.

This model is currently used in high-performance systems (e.g. Arrow, Plasma Store, Ray) with CPython.

It avoids everything you’re concerned about, because Rust manages the memory and Python only holds a memoryview.

Finally, I haven't actually tried it myself, but I'm certain it's true and that it will increase speed by up to 300%.

[gi0baro]

I don't know why you're pitching me the thing, if you can do a safe implementation that doesn't involve cloning/copying good for you!
But stating you can get 3x performance over RSGI would mean Granian spend ~75% of its time doing objects conversions, which is quite far from the truth tbh.

True parallel execution because each interpreter has its own GIL

That's already true even in the multiprocessing (and standard) implementation of Granian, sub-interpreters won't change anything.
And to my perspective, free-threaded – which is already implemented in Granian – is more interesting as it reduces memory consumption.