- Create custom eventloop for asyncio couroutines/tasks/futures rather than using common/default asyncio event loop.
- Since eventloop uses single thread, if the external app is using default
asyncio loop for it's own operations, it can block internal eventloop. Need to create separate eventloop that doesn't use the default asyncio eventloop thread.
- This is also needed since
public APIs can be called asynchronously from different threads or custom eventloop. This will disrupt internal workflow where external eventloops will influence order of the code execution. With current implementation, it will work fine if it's called from a single thread or default asyncio eventloop
- By having a single custom eventloop for whole internal workflow, we make sure all internal operations are thread-safe. So, thread safety-related issues can be avoided ~~> https://github.com/ably/ably~~python/issues/531
- Since ably-clients do heavy network IO operations. use of a single-threaded event loop model should be preferred https://www.pythontutorial.net/python-concurrency/python-event-loop/.
- This is similar to the js single-threaded event loop, which is specifically efficient when file IO or network IO operations are performed.
- This also means the use of multithreading/threadpool (
threading package in python) should be avoided at all costs since it won't be as efficient and there will be an extra overhead to manage shared resources using a thread synchronization means. Also. asyncio objects are not thread safe ( typically not an issue ) and a combination of multithreading and asyncio will introduce complexity to use asyncio threadsafe apis ~~> https://docs.python.org/3/library/asyncio~~dev.html#concurrency-and-multithreading
- The current ably-js client works without the use of multithreading, so most likely we won't need it either. APIs provided as a part of python native
asyncio package should be enough to satisfy spec implementation.
┆Issue is synchronized with this Jira Task by Unito
