Comments by "justanothercomment" (@justanothercomment416) on "Sqlite Is Getting So Good" video.

Not entirely clear, but for that mutex, it should be an async mutex. If using the standard mutex described bug is expected.
10
Yep. And async mutex explicitly exist to avoid this dead lock. For whatever reason they didn't use it. Looks like an application bug and not a rust bug.
7
@hbobenicio It's a mutex which understands Rust's async wait and behaviors correctly for these types of use. Whereas a normal mutex blocks execution as it's becoming recursive, which isn't what you would want for an async operation and its scheduler in the first place. The "deadlock" is the block as requested by the mutex. While making some assumptions as the full context was not provided, it appears this was not a Rust bug but a user bug from using the incorrect mutex for purpose.
5
No cold start can be handled the same way android handles its VMs. You basically pre-fork the initialized base VM (zygot in Android speak IIRC). This way, you're always connecting to a pre-warmed image rather than cold starting on each need.
3
@comradepeter87 I just read several sources including the docs on it. You can doubt all you like. Your doubt is irrelevant. Please go read before you comment further.
2
@comradepeter87 Interesting. Because I looked before I even commented and found async mutexes to be the defacto recommendation. It would appear some of those with "authority" don't really understand what they are saying. Because the async implementation explicitly exists to avoid all of this nonesense.
1