Shared memory features?

[mcharytoniuk]

Hello! :)

I really love Granian. It reminds me of Swoole (https://wiki.swoole.com/en/#/), which is similar in concept but for PHP (which is a good thing to me :)). That is the point of view I'm coming from.

Swoole has some shared memory features, like Table (https://wiki.swoole.com/en/#/memory/table), which is really useful for, for example, storing information about all the WebSocket connections started in the server among multiple workers; also things like Atomics, which are sometimes useful.

I know that similar use cases can be solved with an external in-memory store like Redis, but do you plan to implement shared memory features in the future? If so, do you need some help maybe? I do not mean re-implementing the Redis protocol, just the shared memory slices, atomics, and such, or communicating between the worker threads.

Best wishes!

[gi0baro]

Hi @mcharytoniuk, this sounds quite like the discussion happened in #264.

I feel that some shared memory feature in Granian is quite out of the project scope (at least at the moment), especially considering workers in Granian are separated processes, not threads (at least in the GIL version, we'll see what happens with Python 3.13 and the no-gil version), so that will require inter-process communication rather than just shared memory to address what you have in mind.

I have some plans to add a broadcasting feature to RSGI (think about it like channels) in order to avoid the need of external tools to broadcast messages to websockets connected to different Granian processes, but right now it is just an idea and there's no ETA for that; it's also quite unclear at the moment if it could be added as extension to ASGI as well so other frameworks in the Python ecosystem can take advantage of that in addition to Emmett.

I'd appreciate help on that side, especially in designing the protocol for RSGI inter-process communication (would that be TCP or UDP? Should we define a binary message spec or use something already available? Do we need any sort of consensus algorithm? etc), but I'm not on that page yet :)

[mcharytoniuk]

I'd appreciate help on that side, especially in designing the protocol for RSGI inter-process communication (would that be TCP or UDP? Should we define a binary message spec or use something already available? Do we need any sort of consensus algorithm? etc), but I'm not on that page yet :)

If it were able to expose any shared memory slice, then it would have to spawn threads and be able to allocate it before they fork from the primary process.

In general, I think it would be nice to be able to execute some Python code before forking it. That would mean it would be possible to bootstrap a part of the application, and when a worker fails, it could pick up from a bootstrapped application instead of starting everything from scratch. I don't know how realistic it is to have something like that built-in into RSGI, as it is a huge change in how workers are handled.

[gi0baro]

@mcharytoniuk well, the thing is that Granian won't fork the main process. It uses spawn in place of fork on all the relevant platforms, so it won't be the way to go with Granian.

Somehow it feels to me your point will actually be solved by the free threaded version of Python 3.13. Once that will land, then a no-GIL version of Granian won't need to spawn multiple processes, and thus you can have shared memory across workers as they all we be threads.

[mcharytoniuk]

Thanks for letting me know. That may be the solution, then.

By the way, I am working on an RGSI-based micro-framework. : D I plan to share it soon.

[mcharytoniuk]

@gi0baro Still work in progress, but maybe it will be interesting to you. I have added RSGI support for http among some other features.

https://github.com/distantmagic/intention