libsvn_wc, sqlite, and threads (gstein please read this)

[Stefan Sperling <st...@elego.de>]

Hi Greg and others,

recently I mentioned on IRC that svn from trunk refused to
update its own working copy. It would just print "Skipped '.'"
and exit normally. Turns out that in init_sqlite(), we unconditionally
check sqlite for thread-safety, and bail out if it isn't thread-safe.

Because OpenBSD's pure-userland pthread implementation sets stdin and
stdout to non-blocking, piping stdout from svn linked to libpthread to
tools which aren't using pthreads (such as 'more' and 'less') does not
work too well. So I built all dependencies and Subversion itself
without support for threads.
This caused the skipping problem to appear. Our code is currently written
with the assumption that sqlite has been compiled with support for threads.
I don't know the reason for this requirement. But I guess that we can
assume that people are clever enough not to try to use svn libraries (and
hence sqlite) in a multi-threaded application if APR has been compiled without
thread support. So in accordance with established practice elsewhere, I'd like
to wrap threading-related stuff in init_sqlite() in #if APR_HAS_THREADS,
leaving only the sqlite-version check for the single-threaded case.

The patch below does this and fixes the "Skipped '.'" problem for me.
I can now update my working copies again, and svn diff | less also
works nicely.

Note that I don't know yet why "svn update" was still working for
subdirectories (as in "svn update notes/") but not for the current
working directory. Could this behaviour point to a bug worth hunting down?

Stefan

[[[
* subversion/libsvn_subr/sqlite.c
  (init_sqlite): Wrap threading related-code in #if APR_HAS_THREADS.
]]]

Index: subversion/libsvn_subr/sqlite.c
===================================================================
--- subversion/libsvn_subr/sqlite.c	(revision 39292)
+++ subversion/libsvn_subr/sqlite.c	(working copy)
@@ -648,6 +648,7 @@ init_sqlite(apr_pool_t *pool)
                     SQLITE_VERSION, sqlite3_libversion());
     }
 
+#if APR_HAS_THREADS
 #if SQLITE_VERSION_AT_LEAST(3,5,0)
   /* SQLite 3.5 allows verification of its thread-safety at runtime.
      Older versions are simply expected to have been configured with
@@ -676,6 +677,7 @@ init_sqlite(apr_pool_t *pool)
   SQLITE_ERR_MSG(sqlite3_enable_shared_cache(TRUE),
                  _("Could not initialize SQLite shared cache"));
 #endif
+#endif /* APR_HAS_THRADS */
 
   return SVN_NO_ERROR;
 }

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2394587

Re: libsvn_wc, sqlite, and threads (gstein please read this)

[Stefan Sperling <st...@elego.de>]

On Mon, Sep 14, 2009 at 12:51:19PM +0100, Stefan Sperling wrote:
> [[[
> * subversion/libsvn_subr/sqlite.c
>   (init_sqlite): Wrap threading related-code in #if APR_HAS_THREADS.
> ]]]

Bert pointed out that the shared cache should also work in
single-threaded mode.

I'm running make check on this now.

Stefan

Index: subversion/libsvn_subr/sqlite.c
===================================================================
--- subversion/libsvn_subr/sqlite.c	(revision 39293)
+++ subversion/libsvn_subr/sqlite.c	(working copy)
@@ -648,6 +648,7 @@ init_sqlite(apr_pool_t *pool)
                     SQLITE_VERSION, sqlite3_libversion());
     }
 
+#if APR_HAS_THREADS
 #if SQLITE_VERSION_AT_LEAST(3,5,0)
   /* SQLite 3.5 allows verification of its thread-safety at runtime.
      Older versions are simply expected to have been configured with
@@ -669,10 +670,12 @@ init_sqlite(apr_pool_t *pool)
   }
   SQLITE_ERR_MSG(sqlite3_initialize(), _("Could not initialize SQLite"));
 #endif
+#endif /* APR_HAS_THRADS */
+
 #if SQLITE_VERSION_AT_LEAST(3,5,0)
-  /* SQLite 3.5 allows sharing cache instances in a multithreaded environment.
-     This allows sharing cached data when we open a database more than once
-     (Very common in the current pre-single-database state) */
+  /* SQLite 3.5 allows sharing cache instances, even in a multithreaded
+   * environment. This allows sharing cached data when we open a database
+   * more than once (Very common in the current pre-single-database state) */
   SQLITE_ERR_MSG(sqlite3_enable_shared_cache(TRUE),
                  _("Could not initialize SQLite shared cache"));
 #endif

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2394598