On Mon, Aug 21, 2017 at 9:15 AM, Yury Selivanov <yselivanov@gmail.com> wrote:
Hi Pau,
I personally don't think we need this in asyncio. While the function has a relatively low overhead, it's still an overhead, it's a couple more syscalls on each loop iteration, and it's a bit of a technical debt.
The bar for adding new functionality to asyncio is very high, and I don't see a good rationale for adding this function. Is it for debugging purposes? Or for profiling live applications? If it's the latter, then there are so many other things we want to see, and some of them are protocol-specific.
One approach would be to add a generic instrumentation API. Trio has something like this, that I think is expressive enough to let Pau implement their busyness checking as a library: https://trio.readthedocs.io/en/latest/reference-core.html#instrument-api This has several advantages over subclassing: multiple libraries can define their own instrumentation without interfering with each other, you don't have to redefine the instrumentation for every loop implementation, and you don't have to hook up the instrumentation when setting up the loop, e.g. you could just do something like: import toobusy with toobusy.Monitor(loop) as monitor: if monitor.toobusy(): ... -n -- Nathaniel J. Smith -- https://vorpus.org