[issue33118] No clean way to get notified when a Transport's write buffer empties out

2018-03-22 Thread Yury Selivanov
Yury Selivanov added the comment: > I suppose that it would also be difficult to get buy-in for a feature like > this from the different frameworks? Maybe :) Ideally, asyncio programs should not depend on how exactly tasks are scheduled. --

[issue33118] No clean way to get notified when a Transport's write buffer empties out

2018-03-22 Thread Vitaly Kruglikov
Vitaly Kruglikov added the comment: Yet another paradigm is the likes of `GSource` in gnome's glib. GSource "tasks" added to the event loop are polled by the event loop for readiness before the event loop blocks on select/epoll/etc.. The ones that are ready are removed

[issue33118] No clean way to get notified when a Transport's write buffer empties out

2018-03-22 Thread Vitaly Kruglikov
Vitaly Kruglikov added the comment: I'll have to settle for `set_write_buffer_limits(0, 0)` for my blocking wrapper case. I think that 'write_buffer_drained' callback is a good idea, though. -- ___ Python tracker

[issue33118] No clean way to get notified when a Transport's write buffer empties out

2018-03-22 Thread Vitaly Kruglikov
Vitaly Kruglikov added the comment: > 'events.AbstractEventLoop.run_one_step()' > This is highly unlikely to ever happen. Sure, I can see how that could be a problem with other underlying implementations, such as Twisted reactor. Just wishful thinking :). --

[issue33118] No clean way to get notified when a Transport's write buffer empties out

2018-03-22 Thread Yury Selivanov
Yury Selivanov added the comment: > 'events.AbstractEventLoop.run_one_step()' This is highly unlikely to ever happen. It's hard to define what one iteration of an event loop is, and it would be even harder to get that agreement for all frameworks/event loops that are

[issue33118] No clean way to get notified when a Transport's write buffer empties out

2018-03-22 Thread Yury Selivanov
Yury Selivanov added the comment: Yeah, I think your best option would be to use `set_write_buffer_limits(0, 0)`. You don't need asyncio flow control anyways, as AMQP protocol is unlikely to generate any pressure on IO buffers. --

[issue33118] No clean way to get notified when a Transport's write buffer empties out

2018-03-22 Thread Vitaly Kruglikov
Vitaly Kruglikov added the comment: ... or `events.AbstractEventLoop.run_one_iteration()`. -- ___ Python tracker ___

[issue33118] No clean way to get notified when a Transport's write buffer empties out

2018-03-22 Thread Vitaly Kruglikov
Vitaly Kruglikov added the comment: Thank you for following up. My use case is this: In the Pika AMQP client package, we have a blocking AMQP connection adapter - `BlockingConnection` - wrapped around an asynchronous AMQP connection adapter. Presently,

[issue33118] No clean way to get notified when a Transport's write buffer empties out

2018-03-22 Thread Yury Selivanov
Yury Selivanov added the comment: We'll likely add 'write_buffer_drained' callback method to `asyncio.Protocol` in 3.8. In the meanwhile, the only option would be using `_make_empty_waiter` in 3.7, or set_write_buffer_limits(0, 0). What's your use case, by the way?

[issue33118] No clean way to get notified when a Transport's write buffer empties out

2018-03-22 Thread Vitaly Kruglikov
New submission from Vitaly Kruglikov : There doesn't appear to be an ordained mechanism for getting notified when a Transport's (or WriteTransport's) write buffer drains to zero (i.e., all output data has been transferred to socket). I don't want to hijack