CancelAllBackgroundWork: Flush of unpersisted data waits for stall conditions to clear and delays db close about rocksdb

[hx235]

It's most likely because allow_write_stall in FlushOptions was added later (in 2018). The usage of default FlushOptions here existed before 2016.

I personally think it should be okay to proceed with the Flush(), waiting for stall conditions if users want. The next Open() will then stall for writes early. Maybe it can be configurable parameter passing in CancelAllBackgroundWork()

[Yuval-Ariel]

Sure i can do that.
Im just worried that this new parameter will be too confusing since it means "flush will wait for some stall conditions to clear if there is unpersisted data".
This new parameter will have no effect if theres no unpersisted data.
Also, this might conflict with the already existing parameter of CancelAllBackgroundWork() since a user can pass wait = false and allow_write_stall = false which translates into "dont wait for bg work but wait for stall conditions to clear" (meaning it will wait for some bg work even though wait is false).
Last point is that we'd always want to flush unpersisted data as fast as possible right?
@hx235 what do you think?