Status of __rsgi__ and __rsgi_init__

[2-5]

I'm using __rsgi_init__ to be able to integrate in the event loop a separate piece of asyncio code needed by the app. This was previously requested by other users (how to integrate with asyncio.create_task, ...):

class Service:

    async def init(self):
        self.__db = await ...

    async def on_rsgi(self, scope, proto):
        await self.__db.query ...

_SERVICE = Service()

def init_service(loop: asyncio.AbstractEventLoop):
    loop.create_task(_SERVICE.init())
    # FIXME: wait until _SERVICE.init finishes initialization

class app:
    __rsgi__ = _SERVICE.on_rsgi
    __rsgi_init__ = init_service

server = Granian("service:app")
server.serve()

But __rsgi__ and __rsgi_init__ are not mentioned in the RSGI spec, so I guess they are an undocumented feature used by emmett, but possibly not supported by other future RSGI servers.

So what is their status?

I would also like to request the addition of something like __rsgi_close__ which is called on worker shutdown for graceful exit. You suggested in another discussion subclassing Granian and adding the custom shutdown call after serve returns.

[gi0baro]

@2-5 I'd say both __rsgi__ (which is just to allow apps to be both ASGI and RSGI compatible) and __rsgi_init__ are stable enough to be added to RSGI spec, gonna add those in the following days. __rsgi_init__ might change interface in the future, but we can just issue a major version release of RSGI spec. My general advice for now is to pin Granian versions and check changes before upgrading (like Emmett does).

As for the __rsgi_close__ method, yes, at the moment you can do practically whatever you want by implementing a custom rsgi spawn method. I'm open to add an utility method like that to the spec, but I'd personally name it __rsgi_del__, feel free to open up an issue to request that.

On a side node: if you want to run async code in __rsgi_init__ I suggest you to use loop.run_until_complete in place of loop.create_task.

[2-5]

__rsgi_init__ might change interface in the future

I'm curious how you think it might change. Maybe you want to remove loop? I know that asyncio deprecated the pattern of passing loop as an arg, and instead they recommend calling asyncio.get_running_loop.

On a side node: if you want to run async code in __rsgi_init__ I suggest you to use loop.run_until_complete in place of loop.create_task.

Indeed, that would make more sense for the example I posted above. In the real app I run multiple tasks for the whole duration of the process, so I need create_task to run them concurrently with the web serving.

[gi0baro]

I'm curious how you think it might change. Maybe you want to remove loop? I know that asyncio deprecated the pattern of passing loop as an arg, and instead they recommend calling asyncio.get_running_loop.

No, passing the loop is required as it is not yet running at that point.
It is possible that in the future we need to pass additional arguments, but it really depends on the next features of RSGI.

[gi0baro]

@2-5 jfyi RSGI spec is now mentioning both __rsgi__ and __rsgi_init__ (8059db2)