4 ms·

Filesystem io (and probably more) is not async at the kernel level in Linux. (Just imagine trying to express the complexity of it in continuations or some sort

Filesystem io (and probably more) is not async at the kernel level in Linux. (Just imagine trying to express the complexity of it in continuations or some sort od state machine!) As such io_uring takes the form of a kernel thread pool. Disk block io by contrast is much easier to be fundamentally async since its almost always a case of submitting a request to an HBA and waiting for an interrupt.

wmf 2y ago
Just imagine trying to express the complexity of [a filesystem] in continuations or some sort of state machine! Arguably asyc/await could help with this; obviously it didn't exist in 1991 when Linux was created but it would be interesting to revisit this topic.
- SoothingSorbet 2y ago
  > Arguably asyc/await could help with this; obviously it didn't exist in 1991 when Linux was created Wouldn't that just consist of I/O operations returning futures and then having an await() block the calling thread until the future is done (i.e. put it on a waitqueue)?
treyd 2y ago
> Just imagine trying to express the complexity of it in continuations or some sort od state machine! With Rust in the kernel this becomes somewhat possible to conceptualize.
mananaysiempre 2y ago
> Just imagine trying to express the complexity of it in continuations or some sort o[f] state machine! You’d probably want to use either some sort of code generation to do the requisite CPS transform[1] or the Duff’s-device-like preprocessor trick[2], but it’s definitely doable with some compiler support. Not in an existing codebase, though. (Brought to you by working on a C codebase that does express stuff like this as explicit callbacks and context structures. Ugh.) [1] https://dx.doi.org/10.1007/s10990-012-9084-5 https://dx.doi.org/10.1007/s10990-012-9084-5, https://www.irif.fr/~jch/research/cpc-2012.pdf https://www.irif.fr/~jch/research/cpc-2012.pdf, https://github.com/kerneis/cpc https://github.com/kerneis/cpc [2] https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

wmf 2y ago

Just imagine trying to express the complexity of [a filesystem] in continuations or some sort of state machine! Arguably asyc/await could help with this; obviously it didn't exist in 1991 when Linux was created but it would be interesting to revisit this topic.

SoothingSorbet 2y ago
> Arguably asyc/await could help with this; obviously it didn't exist in 1991 when Linux was created Wouldn't that just consist of I/O operations returning futures and then having an await() block the calling thread until the future is done (i.e. put it on a waitqueue)?

treyd 2y ago

> Just imagine trying to express the complexity of it in continuations or some sort od state machine! With Rust in the kernel this becomes somewhat possible to conceptualize.

mananaysiempre 2y ago

> Just imagine trying to express the complexity of it in continuations or some sort o[f] state machine! You’d probably want to use either some sort of code generation to do the requisite CPS transform[1] or the Duff’s-device-like preprocessor trick[2], but it’s definitely doable with some compiler support. Not in an existing codebase, though. (Brought to you by working on a C codebase that does express stuff like this as explicit callbacks and context structures. Ugh.) [1] https://dx.doi.org/10.1007/s10990-012-9084-5 https://dx.doi.org/10.1007/s10990-012-9084-5, https://www.irif.fr/~jch/research/cpc-2012.pdf https://www.irif.fr/~jch/research/cpc-2012.pdf, https://github.com/kerneis/cpc https://github.com/kerneis/cpc [2] https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html