https://pantsbuild.org/ logo
#development
Title
# development
a

average-vr-56795

05/03/2019, 2:29 PM
@witty-crayon-22786 Remind me, is there a good reason we still have a separate fs_pool and runtime on Core, or have we just not gotten around to unifying them (and maybe switching to tokio-fs) yet?
w

witty-crayon-22786

05/03/2019, 8:52 PM
@average-vr-56795: well, so, sortof.
i think that it is feasible to do, but i think that the issue was that when i last looked, there wasn't an explicit way to mark something as potentially blocking
or, there was, but we'd need to instrument a lot of stuff that currently just runs directly on the iopool in a more finegrained manner...?
basically, iirc, tokio-fs internally used a "maybe blocking" block, but it wasn't 100% clear whether we could just wrap each of the `Fn`s that we currently submit to the io pool using the same mechanism, and have it work
i also think that i got sidetracked into attempting to make things more finegrained here: https://github.com/tokio-rs/tokio/issues/369
i expect that since then they have actually implemented a lot of those methods... but if you see my final comment there, it sortof feels like wrapping an entire sequence of IO operations in a blocking-block is better for some of our io-pooly usecases anyway
...yea, they're all implemented now. so all FS access could happen via tokio-fs, probably
the last thing(s) though would be lmdb and curl
commented on https://github.com/tokio-rs/tokio/issues/369 and closed it in favor of the linked tickets
although it's unclear whether it is a symptom of incorrect usage of those APIs
it's probably worth dumping this in a ticket, sorry.