Tom Forbes added the comment:
Actually reacting to a stall would require something more and probably should
be done at some point.
But this is purely about monitoring - in our use case we'd send a metric via
statsd that would be used to correlate stalls against other service level
me
Change by Tom Forbes :
--
keywords: +patch
pull_requests: +24642
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25990
___
Python tracker
<https://bugs.python.org/issu
Tom Forbes added the comment:
I don't see why we shouldn't use PEP 578 for this - the events provide rich
monitoring information about what a Python process is "doing" with an easy,
central way to register callbacks to receive these events and shovel them off
to a moni
New submission from Tom Forbes :
Detecting and monitoring loop stalls in a production asyncio application is
more difficult than it could be.
Firstly you must enable debug mode for the entire loop then you need to look
for warnings outputted via the asyncio logger. This makes it hard to send
New submission from Tom Forbes :
`functools.lru_cache` has a maxsize=128 default for all functions.
If a function has no arguments then this maxsize default is redundant and
should be set to `maxsize=None`:
```
@functools.lru_cache()
def function_with_no_args():
pass
```
Currently you
Tom Forbes added the comment:
Django recently switched to HTTP 1.1 on their development server, and it works
fine as long as the middleware is included that generates the content length.
Using a 'bare' Django project with no middleware the server will just hang.
It sounds like the e
New submission from Tom Forbes:
The builtin http.server module does not support HTTP keep-alive when sending a
response without a content-length. This causes any clients to hang waiting on
more response data, while the server hangs waiting for the client to send
another request. This is
