On Monday, June 15, 2015 at 10:49:28 PM UTC+3, Guido van Rossum wrote:
> Fair enough. I guess there is a real danger to overwhelm the socket?
> Otherwise you don't even need the drain() call. But it looks like you are
> basically logging as fast as you can, so the drain() seems important.
I still think that this is a relatively rare case and I don't want to
> encourage sharing streams between coroutines. Maybe you can submit a patch
> to turn the assert into a RuntimeError?
My 5c: I'm writing an AMQP client library. The AMQP protocol consists of a
sequence of frames, which may (mostly) be interleaved. I use
StreamWriter.drain() before sending large frames to make sure I'm not
flooding the write buffer. I ran into this AssertionError while testing
publishing messages from multiple tasks works - it didn't. Thinking there's
some inherent reason drain() must be called from only one task, I started
figuring out what logic I need to determine when to call it with the
assumption it returns only when the buffer is empty. Instead it turns out
it has water marks and the works, so I just wrapped the call in async with
I'm not sure the AssertionError is more help than harm, as protocols such
as this one where several tasks may operate on the same protocol just need
to work around it, and protocols that don't support interleaving of writes
probably run into bugs anyway.