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 that are normally fast, but s
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, Dima and Andrew, for your sugg
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 [perhaps with
> mock.pa
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]
* monit
