Author yselivanov
Recipients asvetlov, inada.naoki, lukasz.langa, pitrou, yselivanov
Date 2017-12-11.16:46:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1513010817.71.0.213398074469.issue32251@psf.upfronthosting.co.za>
In-reply-to
Content
> See https://eklitzke.org/goroutines-nonblocking-io-and-memory-usage for an interesting discussion of the drawbacks of some buffer handling idioms.

Thanks for the link!

It does make sense to use a pool of buffers for the proposed BufferedProtocol when you need to keep thousands of long-open connections.  The current design makes that easy: when BufferedProtocol.get_buffer() is called you either take a buffer from the pool or allocate a temporary new one.

For use-cases like DB connections (asyncpg) a permanently allocated buffer per protocol instance is a good solution too, as usually there's a fairly limited number of open DB connections.
History
Date User Action Args
2017-12-11 16:46:57yselivanovsetrecipients: + yselivanov, pitrou, asvetlov, inada.naoki, lukasz.langa
2017-12-11 16:46:57yselivanovsetmessageid: <1513010817.71.0.213398074469.issue32251@psf.upfronthosting.co.za>
2017-12-11 16:46:57yselivanovlinkissue32251 messages
2017-12-11 16:46:57yselivanovcreate