Re: svn commit: r1865522 - /subversion/trunk/subversion/libsvn_subr/sqlite3wrapper.c

[Evgeny Kotkov]

Daniel Shahaf  writes:

> Would it break anything if some application that uses libsvn had
> its own copy of SQLite that was compiled with another
> SQLITE_DEFAULT_MEMSTATUS value?  I don't see anything about that
> in the linked page.

I don't think so, because our amalgamated SQLite has all its symbols marked
as static and is not exposed to anyone else.

Also, this compile option only changes the default value of the corresponding
runtime option (SQLITE_CONFIG_MEMSTATUS), meaning that it can still be
changed later with sqlite3_config().


Thanks,
Evgeny Kotkov

Re: svn commit: r1865522 - /subversion/trunk/subversion/libsvn_subr/sqlite3wrapper.c

[Daniel Shahaf]

kot...@apache.org wrote on Tue, 20 Aug 2019 09:18 +00:00:
> When compiling SQLite, set the SQLITE_DEFAULT_MEMSTATUS=0 compile-time option.
> 
> This is the recommended option that is not enabled by default. Setting it to
> zero avoids using a mutex (and thus suffering a performance penalty) during
> every sqlite3_malloc() call, where this mutex is used to properly update the
> allocations stats.  We don't use sqlite3_status(), so set this option to zero.
> 
> See https://sqlite.org/compile.html#recommended_compile_time_options

Would it break anything if some application that uses libsvn had
its own copy of SQLite that was compiled with another SQLITE_DEFAULT_MEMSTATUS
value?  I don't see anything about that in the linked page.

Cheers,

Daniel