-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Internal use of async #8
Comments
Thanks for opening this issue. I think this is a fair observation and certainly something doable. We can't remove the async wrapper methods even if we wanted to as they're required by the One question is how the sync api (in practice) handles cancellation as compared to the async api. Does the cancellation token for the async SQLite API basically do nothing? |
Yes, it looks like we'd get |
The real question is if there are any cases (not just the straightforward one) where subsequent cancellation works in the asynchronous API (since we already know that the async api is just a wrapper around the synchronous one) that don't work in the synchronous one. As an aside, I'm very surprised that subsequent cancellation in the async API is completely ignored since |
You're right - |
The observation that the cancellation token can be used to abort long-running statements makes the MS advice to avoid async Sqlite calls a little simplistic. |
What are your thoughts on async in Microsoft.Data.Sqlite.Core? I think the following advice is still relevant:
https://docs.microsoft.com/en-us/dotnet/standard/data/sqlite/async
It would be difficult to remove the public Async method signatures on SqliteCache, but perhaps the underlying database operations could be changed to use sync methods and so minimize the async overhead. It's only a very minor consideration.
The text was updated successfully, but these errors were encountered: