Repository navigation
Pre-Compiled Task Objects. #166
Description
Activity
Might also be useful if we write a new task object we should call it UVTask since I would like to utilize a sperate task-name and counter sytem to make things less confusing
"UVTask-1","UVTask-2"and so on (Should be a loop attribute since I hate globals with a passion). It can be safely tied to UVAsync for better speed and UVAsync can theoretically repeat itself while keeping the given tasks alive. This should not use a standard deque either on multiple tasks. (that's slow).Something like this may suffice. Here is my given idea for anybody confused with what I had just said above.
cdef class UVTask(Future): # subclassed from winloop.loop.Future cdef UVAsync stepper_handle # <- Handles __step() aka am_send function for us.
Currently today I am sick and have been sleeping to try and fight it off but I'll use whatever energy I have left to write a duplicate issue for uvloop.
I'm putting an issue down for pre-compiled
winloop.loop.Taskobjects Seems like another one that could easily tackled now thatwinloop.loop.Futurehas been implemented to speedup socket bottlenecks and soon will be set to mainstream to speedup other libraries.Setting
winloop.loop.Taskto the main task might be a good approach and can be replaced with other task factories pretty easily. However I don't see it's improvements being as utilized elsewhere as type casting withwinloop.Loopis my objective to stop some annoying and costly interpreter calls but would be good idea nevertheless. Feel free to let me know what anybody else thinks.#164 for reference.