Don't process close() until current in-flight async ops are complete

[rvagg]

Will involve more tracking like the delete-iterators-on-close work. Each async operation will have to increment a counter when starting and decrement when done, will also need to trigger a possible-close function when done.
Without this, a segfault is possible when you close() while an operation is in-flight.

[dominictarr]

Is this only iterators, or put, get, del, batch also?

[mcollina]

Even adding a counter is hard, because after a call to close, all the subsequent accesses to the database must be ignored.

As I see, every lib implements this thing on its own. Could we build a generic and reusable solution? Even communication protocols have the same problem if they want to close gracefully.

[rvagg]

marked as "help wanted", see the iterator tracking functionality for how this could work since we hold up close() until iterators are closed and can also force close of iterators when close() is called.

[ralphtheninja]

@dominictarr I believe it involves all in flight operations (see #157)

[ralphtheninja]

@mcollina The counter would have to be static I guess.

[martinheidegger]

Shouldn't this be a feature of levelup, I mean: It is sort of a pain to do this for every client.

[ralphtheninja]

Or maybe in abstract-leveldown?

[martinheidegger]

In any case https://github.com/Level/levelup#dbclosecallback doesn't mention this case and at the minimum it should state what the should-case should be.

[ralphtheninja]

Nice!