On Tue, Jun 22, 2010 at 9:15 AM, Pavel Ivanov <paiva...@gmail.com> wrote:
> > The idea is that the copy and nulling happens very quickly where the > > sqlite3_close is more expensive, do the copy/null very quickly so that if > > another thread calls Close during the first threads execution of > > sqlite3_close, the second thread finds m_db null and will not call > > sqlite3_close. > > Wow, if you really relied on that then you did too few of > mutli-threaded programming. The rule of thumb is: no matter how fast > you think 2 different operations execute there always will be a > situation when another thread executes something between those 2 > operations (and that "something" can be a very big chunk of code). So > you must protect it with some mutex or you can use atomic swaps (but > they are platform- and compiler-dependent). > Yea, I know it isn't as safe as it should be, but in this case it is one class per thread. Why I am doing it, I don't know, old habit that I just cannot seem to break. In light of your next statement, I think I will change it;) > Another problem with this code (which is not related to the crash): do > you know that sqlite3_close can return SQLITE_BUSY when there are some > statements or BLOB handles still open and not finalized? > No, I did not. I am not storing any blobs right now, but... Is the busy handler going to kick in? I know the busy handler is not the sole answer to the problem, but it does seem to catch most of my SQLITE_BUSY issues since all data is pretty small. Sam _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
