Message310050
> 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. |
|
Date |
User |
Action |
Args |
2018-01-16 08:51:33 | pitrou | set | recipients:
+ pitrou, benjamin.peterson, stutzbach, njs, martin.panter, xgdomingo |
2018-01-16 08:51:33 | pitrou | set | messageid: <1516092693.0.0.467229070634.issue32561@psf.upfronthosting.co.za> |
2018-01-16 08:51:32 | pitrou | link | issue32561 messages |
2018-01-16 08:51:32 | pitrou | create | |
|