Sled: Flusher should be a trait and the current implementation should be a BackgroundThreadFlusher

[thedrow]

Currently the Flusher is too concrete.
It's interface explicitly relies on using a thread.
In addition, there's no way to implement the run method differently which prevents extension.

Theoretically the Flusher could be implemented using an event loop such as tokio instead of a thread.
The current implementation is the only Flusher implementation possible because the type is hardwired into the context object.

[spacejam]

tokio uses threads. this is simpler.

[spacejam]

flusher was more abstract in the past, but it actually significantly complicated some debugging efforts, which it tends to highlight in some situations

[thedrow]

But if we do eventually support #571 it might be a good idea to make it more abstract.

In addition, if we wanted to make sled collaborate with event loops other than tokio which is useful for bindings this kind of interface prevents that.

Tokio should not use threads after async/await in this case as it is possible to schedule a coroutine after N seconds. This is what happens in Python with asyncio/trio.

[spacejam]

It's unclear how badly pushing all of this through a runtime would degrade throughput. It is clear that it would make debugging harder and general coding slower. sled is not completely a low-latency system, as we need to also make a lot of high throughput considerations. async is more for things that look like load balancers than things that need to be high throughput.

I wrote more about this here https://www.reddit.com/r/rust/comments/cggm4m/hardware_for_async_rust_in_production/eujjo5v/

Also I will never support anything that is based on tokio due to the way that the creator has harassed friends of mine who are building better abstractions (that he keeps stealing ideas from without attribution).

[spacejam]

In this case, we want to use a different thread always because it is the most straightforward way to increase parallelism. [insert rob pike rant]

It's possible that some of the tree methods might have an alternative async interface at some point down the line, but sled is already heavily async on the writepath and reads are usually served from memory in any use case I'm aware of so far. Because so much correctness-critical architecture is changing so fast internally, I spend a lot of time fixing bugs. Adding async right now would significantly degrade the debugging story, and would be bad for the project actually getting released as something other than alpha in the next year.