Sounds good. Just wanted to confirm that. It’s already a good thing to have that segfault squared away.
I do think there are small chances for a segfault, but that latest fix will stop the major one where tons of timeouts would crash the erlang process.
It’s possible to yield a nif back to the main scheduler but it would require quite a bit of refactoring I imagine, and introduce new complexity. And also it might impose requirements in the sqlite API that aren’t supported.
This project demonstrates various flavors of nifs, including one that yields.
It might be possible to signal a cancel to a yielding nif, but that’s not something I’ve done before.
Yes the current iteration is a dirty nif, which initially I thought was the best way to approach this. But I’ve had a few people reach out to me about a use case where they are trying to delete a lot of records in one go and it simply times out, but the query keeps running in the background.
The work around solution for that is to batch deletes instead of doing a huge write operation like that.
I might try out yielding nifs, or just make the disclaimer that query timeouts can happen and they will continue to run until complete.
