Add BackgroundWriteDatabase

[tybug]

See Zac-HD/hypofuzz#41 (comment); was something like this what you were thinking of?

(I expect coverage to fail here; explicit covering test pending)

[Zac-HD]

Yep, this is pretty much what I was thinking.

It might be nice to check for nesting somehow, but I'm not sure it's worth the trouble or complications for users. And maybe we should have fuzz_one_input use this?

[tybug]

hmm, without a way to expose db.join, I wonder if adding this to fuzz_one_input is more trouble than it's worth. I did add it and then promptly got test failures (e.g. test_fuzz_one_input[BytesIO]) due to race conditions. If a fuzz_one_input consumer is try/catching exceptions - the only case where background db writes makes a difference - then they are probably interested in analysis of the database...but admittedly are also unlikely to check the db so promptly as to run into this.

[Zac-HD]

hmm, without a way to expose db.join, I wonder if adding this to fuzz_one_input is more trouble than it's worth. I did add it and then promptly got test failures (e.g. test_fuzz_one_input[BytesIO]) due to race conditions. If a fuzz_one_input consumer is try/catching exceptions - the only case where background db writes makes a difference - then they are probably interested in analysis of the database...but admittedly are also unlikely to check the db so promptly as to run into this.

Eh, fair enough. Let's just suggest in the fuzz_one_input docs that you may wish to use BackgroundWriteDatabase for performance reasons, noting that writes might be delayed (or dropped at shutdown) as a downside.

[Zac-HD]

Is there a convenient way to also retrieve the enqueued-but-not-finalized values? Should we wait for the queue to empty (at least of writes), and then fetch?

[tybug]

I think we don't want to deal with retrieving enqeueued-but-not-finalized values because then we have to replicate the semantics of move + delete, and may start disagreeing with an unsound database which doesn't respect the method contracts. Which wouldn't really be our fault, but still.

I think joining on fetch would be reasonable? (note that the queue is only writes, fetches aren't enqueued). Possibly we want a join: bool = True or timeout: int | None = None parameter.

[tybug]

"join before fetch" cleans up test usages as well, which makes me more confident this is the correct default behavior.

[Zac-HD]

Nice, yeah, join-on-fetch is clearly the way to go 👍