[redland-dev] Threads

[Dave Beckett]

Michael Stahl wrote:
> Brendan Hahn wrote:
>> No response to my message of last week, so let me try again.  It's
>> pretty simple: librdf_cache_set_common locks the world mutex, calls
>> librdf_cache_cleanup, which calls librdf_cache_delete, which locks the
>> world mutex.  pthreads mutexes are non-recursive by default, thus
>> deadlock.  So I can fix this by setting PTHREAD_MUTEX_RECURSIVE at init
>> time, but how was this supposed to work?
>>
>> Further, there's this from librdf_free_cache: LIBRDF_FREE(librdf_cache,
>> cache);
>>
>> #ifdef WITH_THREADS pthread_mutex_unlock(cache->world->mutex); #endif
>>
>> So I'm just not feeling confident about Redland's thread support in
>> general.  Can anyone allay my concerns?
> 
> [oops, it seems gmane ate my first reply...]
> 
> well, the thread support in redland (i'm using version 1.0.8 currently) is
> only for unix (pthreads); unfortunately i need it to work on win32 as
> well, so i've wrapped the librdf_world with a mutex.
> 
> (oh, and it is indeed _the_ librdf_world; create only one instance per
> process, and never free it; unfortunately it does not encapsulate its
> dependencies very well, and freeing a librdf_world will e.g. result in
> freeing the global data of libxml2, which makes other users of libxml2
> rather unhappy)... of course, this is ultimately awful design on libxml2's
> part: global variables are Evil(TM)...)

yes, libxml2 is a bit broke in this regard, especially in the area of error
handlers which are mostly static unless you use some newer functions.

(Curl also has static parts but is properly usable by multiple threads as
far as I can tell).

Raptor's the thing that deals with libxml and there are already some do/do
not free flags for the error handler functions.  See
  raptor_world_set_libxml_flags()
if necessary we can add more and figure out a way for redland to pass this down.

Dave