running asyncio eventloop inside a thespian actor

Skip to first unread message

Balaram Usov

Apr 29, 2020, 7:46:04 PM4/29/20

Hello! I am very interested in thespian as the most suitable solution for the actor model which I want to use in framework which I'm developing now.

So the story is I like to make chat bots. And basically I design telegram bots. In an attempt to

accumulate my knowledge about bot development, I decided to develop high level actor model bot library. There are actually some good bot libs in python for telegram bots, but they're kinda low-level, the engine is just an event loop that scatter incoming updates on handlers

I want to develop a framework where you just set up action->state->trigger flow. Now I roughly imagine architecture like this:

There are Sessions, it’s basically linked to a chat/user, which is a way of storing current state and saying what to do next. Bunch of Sessions is combined into Worker, which is Actor with it's own eventloop. Also somewhere where is a HttpServer Actor that receives messages asynchronously and sends them (via ActorSystem) to the Workers with appropriate session. So Worker is just picking right session, session says which coroutine should be applied to this message, and this coroutine passed to eventloop.

So the question is, is there any potential problems with this design, is it good idea that each Worker-Actor will have it’s own eventloop for asyncio? I see no problems with it, but if someone has already done this, I would be very glad to take a look. Also besides the standard asyncio eventloop there is a faster uvloop, so I just specify that I will most likely use it instead.

And finally, the fact that you support this framework is very cool, I think that thespian attracted me so much because of the good support.

Kevin Quick

Apr 30, 2020, 5:51:58 PM4/30/20
to Balaram Usov,
Hi Balaram,

Behind the scenes each Actor (when using a multiproc base like multiprocTCPBase) is waiting on a select() operation to perform asynchronous sends/receives on the socket(s) it is using.  When a message is received, it calls the actor's receiveMessage; the expectation is that the message is processed and when that method returns, the underlying thespian code for that actor returns to the select() call.

I don't believe that the async eventloop/uvloop will work correctly with the blocking calls to select() as you are intending.  

Instead of mixing concurrency models, it may work better to consolidate on just one model.  An actor-centric model would probably involve having an actor for each session.  This would probably simplify the state management for the session since it would just be the member variables in that Actor instance instead of having to index them by session ID.  You could still have a multi-layer dispatch through the Worker if that was better for your uses, but the worker would relay the incoming message to the actor for that session.

One Thespian feature that may be helpful for you is using the "Watched File Descriptors" feature (  You would use this if an actor needed to perform some kind of potentially blocking I/O operation (such as sending a post message to a chat server): if you have the socket file descriptor available for that operation, you can set it to non-blocking and then return that descriptor from the actor's receiveMessage method in a ThespianWatch object (  Thespian will include that descriptor in the select() list; when that descriptor is readable or writeable then your actor's receiveMessage will be called with a WatchMessage ( to indicate that status.

Hopefully this is helpful, and thank you for your kind words about Thespian!


You received this message because you are subscribed to the Google Groups "" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Reply all
Reply to author
0 new messages