> its size is 0.
Opening an existing read-only database with data in it — implied by your use of the "reset" language — will not drop the database file to 0 size. Only opening a database in a writable directory will do that.
If that's all you want, then I don't see what you're looking for beyond
unlink("mydb.db");
sqlite3_open("mydb.db", &dbhandle);
There's your `DROP DATABASE`.
> I am not sure whether VACUUM locks the database.
[If only there were a way to be sure...](https://www.sqlite.org/lang_vacuum.html) (Hint: search for the word "lock" on that page.)
> side effects that I haven't thought of
Calling [`truncate(2)`](https://man7.org/linux/man-pages/man2/truncate.2.html) on someone else's file is a great way to cause file corruption when another process tries to write into its still perfectly-good file handle.
At least with removing the old file and creating a new one, POSIX file semantics permit the old process to hang onto its doomed instance of the old file name until it closes it. Only once all the open FDs are closed will the file actually disappear from the filesystem.
But beware: if you're using WAL with this scheme, they'll fight over the SMH and WAL file names, again causing corruption.
Once again, I think you need to provide more detail about the actual use case instead of prescribing solutions ahead of knowledge.