Re: [Async-sig] avoiding accidentally calling blocking code

2018-02-14 Thread Nathaniel Smith
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

Re: [Async-sig] avoiding accidentally calling blocking code

2018-02-14 Thread Andrew Svetlov
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,

Re: [Async-sig] avoiding accidentally calling blocking code

2018-02-14 Thread Chris Jerdonek
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

Re: [Async-sig] avoiding accidentally calling blocking code

2018-02-12 Thread Andrew Svetlov
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

Re: [Async-sig] avoiding accidentally calling blocking code

2018-02-12 Thread Dima Tisnek
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] *