Root async infects the entire codebase. Outside of fetching stones remotely, all other work we do from moss is filesystem based, which is effectively blocking work. It didn't make sense to have a mess of async everywhere in this context, especially for heavy blocking tasks like stone reading / writing.
Instead of making async the default, let's make blocking the default and then have very specific sections of code where we block on an async task (fetching stones for caching, for example).
Benchmark
moss index
Testing the moss index command since it was pointlessly async before, which had some overhead when reading stone files:
moss install (n confirmation to bail)
install heavily relies on meta DB calls to build the DAG and resolve pacakges. This shows that there's no regression in DB performance by making DB "blocking". This makes sense because we limited our DB to sequential use via Mutex previously, even if it was used in an async context. Now it's used in a blocking context, sequentially and around the same run time. Note run time is high here because we need to optimize our transaction / DAG code, if possible.
Root async infects the entire codebase. Outside of fetching stones remotely, all other work we do from
mossis filesystem based, which is effectively blocking work. It didn't make sense to have a mess of async everywhere in this context, especially for heavy blocking tasks like stone reading / writing.Instead of making async the default, let's make blocking the default and then have very specific sections of code where we block on an async task (fetching stones for caching, for example).
Benchmark
moss index
Testing the
moss indexcommand since it was pointlessly async before, which had some overhead when reading stone files:moss install (
nconfirmation to bail)installheavily relies on meta DB calls to build the DAG and resolve pacakges. This shows that there's no regression in DB performance by making DB "blocking". This makes sense because we limited our DB to sequential use via Mutex previously, even if it was used in an async context. Now it's used in a blocking context, sequentially and around the same run time. Note run time is high here because we need to optimize our transaction / DAG code, if possible.