You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of close() for SqliteConnection is basically a no-op, relying on the drop method to close the connection. However, the connection handle is also owned by the statement worker thread, and so it will not be dropped until that thread polls the statement command queue and finds it empty. In effect, this means that there can be a noticeable delay between awaiting close() and the database connection actually being closed – this means that it is not (consistently) safe to close the database and then immediately try to remove the database file.
It looks like some refactoring would be necessary to make this work as expected, perhaps using an async channel to await the actual drop of the connection handle.
The text was updated successfully, but these errors were encountered:
It wouldn't be that bad, just add another variant to the StatementWorkerCommand enum with a one-shot channel, then send a message on that channel after dropping conn in the thread.
The current implementation of close() for SqliteConnection is basically a no-op, relying on the drop method to close the connection. However, the connection handle is also owned by the statement worker thread, and so it will not be dropped until that thread polls the statement command queue and finds it empty. In effect, this means that there can be a noticeable delay between awaiting close() and the database connection actually being closed – this means that it is not (consistently) safe to close the database and then immediately try to remove the database file.
It looks like some refactoring would be necessary to make this work as expected, perhaps using an async channel to await the actual drop of the connection handle.
The text was updated successfully, but these errors were encountered: