Add note about Sled 1.0 and Thread Safety in TODO.md
This commit is contained in:
parent
f55a7011dc
commit
77abf536f6
20
TODO.md
20
TODO.md
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue