Library doesn't allow async processes

[faizann]

Hi

I have noticed that once run is called the library goes into a loop of reading/blocking on websocket. This means that you lose control on your process after calling run.
This makes building multiprocessing/multithreaded applications impossible.

I suggest a way to make the reading part non-blocking so that app can do other things like use queues for multiprocessing. I suspect this library will not work very well on high loads where ARI apps has to do DB queries or making other HTTP API calls that can take a few seconds to respond.

[Caesar305]

Hi @faizann can you kindly explain your concern? We are currently working on a very large python project and we are concerned with your findings. Is there a way we can reproduce this issue? We have done several stress tests with no impact that we have noticed.

[faizann]

It has been a while since I looked at this code. We decided not to use Python library and went with GO as a language for better async processing.
The issue is 2 fold
1-- Python itself is very bad with multi-threading. Hence forking and queues need to be used which make things more complicated. Unlike GO where you can have go funcs that are easy to create and can still share memory if needed.
2-- The ARI library runs the websocket code is for obvious reasons is single threaded and runs in the main loop. This makes it harder to handle bigger traffic.

All in all it is just python and the architecture of python that limits the most.

[ldo]

So they didn’t use asyncio to support a non-blocking event loop.

As alternatives that take advantage of coroutines, there is asyncari, or my own Seaskirt.