Message310050
| Author |
pitrou |
| Recipients |
benjamin.peterson, martin.panter, njs, pitrou, stutzbach, xgdomingo |
| Date |
2018年01月16日.08:51:32 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1516092693.0.0.467229070634.issue32561@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> And all the async file IO APIs I know [1][2][3] have the public API of "just like regular files, but the blocking methods are async". 99% of the time, that means TextWrapper and BufferedStream. So I just don't see any way to get the advantages of this feature without either (a) adding buffer-only support to those layers, or (b) forking those layers into a 3rd-party library, and then adding buffer-only support.
Yeah... The concrete problem is that there's already a poorly thought-out "non-blocking mode" that only partly works, and suddenly the code (which includes a lot of delicate, performance-critical C code... to give you an idea, even recently a consistency bug in truncate() was discovered) will have to be massaged to support another non-blocking mode of operation.
So that's why I'm very cautious about integrating this into BufferedReader and friends. |
|