Closed cirospaciari closed 2 years ago
Added asyncio async/await preliminar support until libuv integration is really done
The current solution for async/await is buggy becauses tries to call response in another thread (only is an issue when aborted, an only some times, i think the asyncio thread is sending .end() when the abortion occurs at the same time in the uWS thread), and if you have a lot of pressure (requests) you can get segmentation fault, is reproducible with pure C/C++ and using 2 loops (1 in each thread). The final solution is to integrate libuv with asyncio and use the same loop. The current solution is for testing only, reimplementing the uvloop with CFFI and changing loop.py will give us an transparent fix.
Reimplement the entire uvloop will take some time, so to fix the current issue when an response is async maybe i will make an wakeup call to invoke uws instead of calling directly. http://docs.libuv.org/en/v1.x/async.html
In Ruby Reactor will run in the same thread with libuv prepare + reactor.run_once https://github.com/socketry/async/tree/main/guides/event-loop
I really wish asyncio had a run_once call, i will test this bizarre thing:
def run_once(loop):
loop.call_soon(loop.stop)
loop.run_forever()
To try to run once step in the main thread instead of using another thread, i hope this works. http://docs.libuv.org/en/v1.x/prepare.html
run_once hack for asyncio worked! but is still slow ( in some tests i got between 30~40k requests per second async instead of 170k sync)
I will wait for Hpy version from uvloop to mature and then integrate with uvloop instead of rewrite the entire uvloop ( if takes too long I will considere an CFFI version)
This will be closed and soon I will commit and merge the changes. I will reopen when I decides about uvloop
uvloop is not working in PyPy maybe a fork could fix and add a function to get the event loop pointer and pass to uWS C API