The doc for SleepCurrentThread says that it may be used for any thread. Can I take it, therefore, that this includes the main thread? And, if the main thread is sleeping, does this mean that other threads can run? Are timers and events blocked if the main thread is sleeping?
No - the main run loop isnât really a âthreadâ in the Xojo sense of the word.
And yes to the second part. Not a good idea to sleep the main run loop
OK. What happens, then, with SQLite when a busy-timeout is set to avoid getting âDatabase is lockedâ? That seems to call the OS sleep mechanism, judging by the SQLite source. If I want to have a number of threads (including the main thread) accessing some number of databases, then I need either to use the timeout feature supplied, or implement my own. Either way, for the main thread that seems to imply a problem.
Should I avoid having the timeout for SQLite calls on the main thread?
If you want to see how mad the OS gets at you go ahead and try âApp.SleepCurrentThread(30000)â. 
I canât see any reason you would like to do that unless you want to test how angry people get with the damn beachball or the spinning wheel of death.
1 Like
Perhaps Timâs idea was that if you could sleep the main âthreadâ, other threads would speed upâŠ
If a database operation is done on the main thead, and you want to avoid getting âDatabase is lockedâ, you have to sleep the main thread and try again in the case where the operation returns SQLITE_BUSY.
You may be using the wrong hammer. Look at @olivierV issue and @Christian_Schmitz solution on this thread: The entire app hangs during the SQLITE timeout. This may be very similar to what you are attempting to work around.
Oh sure. Iâve been doing some testing today, and the entire app will hang during the period that an SQLite call on the main thread has to wait for another program or thread to give up a lock it has on a database. And thereâs no way to avoid this, assuming you donât want the SQLite call to immediately return SQLITE_BUSY (Database is locked).
If you set a timeout of (say) 60 secs on a connection, and the SQLite select you are doing in your Xojo app cannot proceed because another task (such as the sqlite3 CLI in a Terminal window) has an exclusive lock on the database, then after 60 secs your app will get SQLITE_BUSY from that select attempt - unless the other program relinquishes the lock. As soon as it does that then your appâs select succeeds and everything is peachy.
Xojoâs implementation for this appears to internally retry the operation in a tight loop, using 100% CPU. My testing showed that the Xojo app âseesâ the lock being released pretty much immediately.
Sorry, what I meant to say was the perhaps you could try Christianâs implementation (i.e. âdifferent hammerâ) and it could give you better results. I do realize that comes with a cost (both monetary and time-wise) and is probably not what you were asking for. Again, my bad for not really reading more carefully. I do still maintain that you donât want to sleep the main thread though; either OS just punishes the app badly when you do this (and the user may start throwing things at the screen - I caught myself doing that).