This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author njs
Recipients YoSTEALTH, benjamin.peterson, giampaolo.rodola, martin.panter, njs, pitrou, stutzbach, xgdomingo
Date 2018-06-10.12:05:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1528632310.54.0.592728768989.issue32561@psf.upfronthosting.co.za>
In-reply-to
Content
The idea here is *not* to avoid using a thread pool in general. When the data is on disk, using a thread pool is (a) unavoidable, because of how operating system kernels are written, and (b) basically fine anyway, because the overhead added by threads is swamped by the cost of disk access. So for the foreseeable future, we're always going to be using a thread pool for actual disk access.

But, if the data *is already in memory*, so the read can succeed without hitting the disk, then using a thread pool is *not* fine. Fetching data out of memory is super super cheap, so if that's all we're doing then using a thread pool adds massive overhead, in relative terms. We'd like to skip using the thread pool *specifically in this case*.

So the idea would be: first, attempt a "buffer-only" read. If it succeeds, then great we're done and it was really cheap. Otherwise, if it fails, then we know we're in the data-on-disk case, so we dispatch the operation to the thread pool.
History
Date User Action Args
2018-06-10 12:05:10njssetrecipients: + njs, pitrou, giampaolo.rodola, benjamin.peterson, stutzbach, martin.panter, YoSTEALTH, xgdomingo
2018-06-10 12:05:10njssetmessageid: <1528632310.54.0.592728768989.issue32561@psf.upfronthosting.co.za>
2018-06-10 12:05:10njslinkissue32561 messages
2018-06-10 12:05:10njscreate