Accuracy of async call() concurrency warning

[tt2468]

So I've used call() before for simple applications where I'm only ever really calling something once at a time, but I'm working on a quite complicated logic router, which may have calls pend for upwards of 3-5 minutes depending on the task.

The docs for async call() have a very similar warning to the sync call(), warning about what appears to be thread safety. Looking into the code for sync call(), I see that it increments a counter for an id, so not threadsafe. But with asyncio there isn't really that worry. So is the warning for the async call() function still accurate?

https://python-socketio.readthedocs.io/en/latest/api.html#socketio.AsyncServer.call

Just want to make sure I'm not risking undefined behavior.

Thanks

[miguelgrinberg]

Couple of things.

The call() method is a wrapper that combines an EVENT packet sent to the other side with the corresponding ACK packet sent in return. The purpose is for the recipient to "acknowledge" that the event was received. My personal opinion is that you are abusing this feature a bit by making it be a return a result after a long task. While it is not a problem to have long running events, there isn't really much of a benefit for these long tasks versus using HTTP, which is much easier to manage (still my opinion).

The thread safety warning is not specific to call(), the same warning appears in the emit() method. It is not a design goal of this package for these methods to be thread safe. Some events are split into multiple packages, for example, so they cannot be sent atomically. This counter that you found is another possible issue when using ACK packets.

So basically, even if you find a combination that works today, I cannot guarantee that this will continue to work, because I'm not aiming to support nor testing thread safety. What you can do if you need a thread safe call() is to implement your own version of it, with a Lock that is used only for the emit, but not while waiting for the callback to be received.