[Python-ideas] PEP 3156 / Tulip question: write/send callback/future

[Eli Bendersky]

On Fri, Jan 18, 2013 at 1:02 PM, Guido van Rossum <guido at python.org> wrote:

> On Fri, Jan 18, 2013 at 6:56 AM, Eli Bendersky <eliben at gmail.com> wrote:
> > I'm looking through PEP 3156 and the Tulip code, and either something is
> > missing or I'm not looking in the right places.
> >
> > I can't find any sort of callback / future return for asynchronous
> writes,
> > e.g. in transport.
>
> I guess you should read some Twisted tutorial. :-)
>

Yes, I noticed that Twisted also doesn't have it, so I suspected that
influence.


>
> > Should there be no "data_sent" parallel to "data_received" somewhere? Or,
> > alternatively, "write" returning some sort of future that can be checked
> > later for status? For connections that aren't infinitely fast it's
> useful to
> > know when the data was actually sent/written, or alternatively if an
> error
> > has occurred. This is also important for when writing would actually
> block
> > because of full buffers. boost::asio has such a handler for async_write.
>
> The model is a little different. Glyph has convinced me that it works
> well in practice. We just buffer what is written (when it can't all be
> sent immediately). This is enough for most apps that don't serve 100MB
> files. If the buffer becomes too large, the transport will call
> .pause() on the protocol until it is drained, then it calls .resume().
> (The names of these are TBD, maybe they will end up .pause_writing()
> and .resume_writing().) There are some default behaviors that we can
> add here too, e.g. suspending the task.
>
>
I agree it can be made to work, but how would even simple "done sending"
notification work? Or "send error" for that matter? AFAIR, low-level socket
async API do provide this information. Are we confident enough it will
never be needed to simply hide it away?

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130118/c1772aac/attachment.html>