On Wed, Feb 14, 2018 at 12:42 AM, Chris Jerdonek
wrote:
> Thanks, Dima and Andrew, for your suggestions.
>
> Re: loop.slow_callback_duration, that's interesting. I didn't know
> about that. However, it doesn't seem like that alone would work to
> catch many operations
Mocking everything sounds promising but the problem is in *everything* word.
slow_callback_duration is a viable compromise.
Personally I don't care about fast blocking IO until it is really very fast.
On Wed, Feb 14, 2018 at 10:42 AM Chris Jerdonek
wrote:
> Thanks,
Thanks, Dima and Andrew, for your suggestions.
Re: loop.slow_callback_duration, that's interesting. I didn't know
about that. However, it doesn't seem like that alone would work to
catch many operations that are normally fast, but strictly speaking
blocking. For example, it seems like simple disk
loop.slow_callback_duration + PYTHONASYNCIODEBUG=1
Does it fork for you?
Do you need extra info?
On Tue, Feb 13, 2018 at 7:07 AM Dima Tisnek wrote:
> Let me try to answer the question behind the question.
>
> Like any code validation, it's a healthy mix of:
> * unit tests
Let me try to answer the question behind the question.
Like any code validation, it's a healthy mix of:
* unit tests [perhaps with
mock.patch_all_known_blocking_calls(side_effect=Exception)]
* good judgement [open("foo").read() technically blocks, but only a
problem on network filesystems]
*
Hi,
This is a general Python async question I've had that I haven't seen a
discussion of. Do people know of any techniques other than manually
inspecting code line by line to find out if you're accidentally making
a raw call to a blocking function in a coroutine?
Related to this, again, outside