Is the assert still there? Maybe someone should just submit a PR with a fix? (Although it's too late for 3.6.0, it may make it into 3.6.1 since it feels like a bugfix to me.)
On Tue, Nov 29, 2016 at 8:01 AM, Mathias Fröjdman <m...@iki.fi> wrote: > 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 > an asyncio.Lock. > > 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. > > -- > Mathias > -- --Guido van Rossum (python.org/~guido)
