On Mon, Aug 21, 2017 at 9:15 AM, Yury Selivanov <[email protected]> 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
_______________________________________________
Async-sig mailing list
[email protected]
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/
