> 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).
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?
Pavel
On Tue, Jun 22, 2010 at 3:27 AM, Sam Carleton
<scarle...@miltonstreet.com> wrote:
> Jay,
>
> Thank you! I believe you pointed me at the correct direction. The logic I
> am using of copying the m_db to a temp var, setting the m_db to null prior
> to calling the close method comes from my days of working with Microsoft
> COM. 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. Of course it would help if I actually NULLed out m_db,
> rather than did a compare on it! I shake my head at myself sometimes.
> Thanks a million Jay, I really appreciate it!
>
> Sam
>
> On Tue, Jun 22, 2010 at 12:06 AM, Jay A. Kreibich <j...@kreibi.ch> wrote:
>
>> On Mon, Jun 21, 2010 at 11:56:09PM -0400, Sam Carleton scratched on the
>> wall:
>>
>> > I am NEVER capturing anything in the log file, so it looks like
>> everything
>> > is returning the correct. I am a bit stumped right now, so if it is
>> alright,
>> > I am going to post my code:
>>
>> If you're doing a double close, it won't log an error, it will just
>> crash.
>>
>> > void CSQLiteDB::Close()
>> > {
>> > if(m_db)
>> > {
>> > sqlite3 *db = m_db;
>> > m_db == NULL;
>>
>> No.
>>
>> > sqlite3_close(db);
>> > }
>> > }
>>
>> If you're manually calling ::Close() anywhere, when the object is
>> destroyed it will do a double close.
>>
>> -j
>>
>> --
>> Jay A. Kreibich < J A Y @ K R E I B I.C H >
>>
>> "Intelligence is like underwear: it is important that you have it,
>> but showing it to the wrong people has the tendency to make them
>> feel uncomfortable." -- Angela Johnson
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
