asonix/hyaenidae
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add note about Sled 1.0 and Thread Safety in TODO.md

Browse source
This commit is contained in:
asonix 2021-01-17 22:52:52 -06:00
parent f55a7011dc
commit 77abf536f6
1 changed files with 20 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
TODO.md
View file

@ -4,11 +4,31 @@
It's not out yet, and not everything has a beta release yet, but we should continue tracking the
status of 4.0 and update our libraries as we can.
## Sled 1.0
As of the time of writing, the official Sled 1.0 release date is in two days. I'm not sure how much
the API will change, but I can assume there will be changes around flushing and transactions, as
those have been the subjects of recent PRs against Sled. Most of the other PRs against Sled in the
last month or so have been about reducing memory usage by employing a variety of fancy techniques
backed by whitepapers.
## Async
A lot of logic in the Profiles and Submissions modules synchronously accesses Sled, which is an
issue because Sled is potentially blocking. All of the Big Dangers (transactions) are safely on a
threadpool already, but a couple iterations are currently occuring directly on the Arbiters.
## Thread-safety
A lot of cloning of tree stores is done because the State object itself isn't Send or Sync, which is
caused by it containing an Actix Web Client. This could easily be changed by just putting the Client
into it's own `.data` on the Application, and then State could be passed around between threads in
it's own `Arc`. This would probably marginally improve performance, since we'd not be `Clone`ing an
imperial tonne of sled Trees every time we wanted to do something on a threadpool. It would also
eliminate the need to separate the `State` type and the `Context` type in hyaenidae-profiles, and we
could get rid of that distinction.
It would also mean we could construct the state Just Once :tm: and pass it or clone it around to
each thread that needs it, rather than instantiating the state uniquely for each thread. This would
give us the benefit of not panicking in the background jobs constructor.
## Organization
A lot of modules in hyaenidae-server have circular dependencies, and a few are more than a thousand
lines long, each. These should be separated where possible into smaller modules which create a