[Xapian-discuss] Perl threads and Xapian - incompatibility?

[Ron Kass]

Hi Olly


I'm not sure what you mean by work-around..

The sample code was just a short code to reproduce the problem. This is 
not the real code we have.

Since the actual code is much more complex, it is impossible to move the 
database-open below the threads creation and in fact, the database is 
actually needed all throughout the code and even before the first 
threads are even created.


I guess the actual fix for the problem is making Xapian thread-safe (or 
at least the perl implementation of it, if the C++ one is already so).

I am not sure yet how, but one idea I had is this.

When a Xapian object is created, its thread ID can be stored along with 
it. Upon call to the destructor, the code will check in the stored 
thread ID is the one that is actually calling the destructor.

If not, the actual object destructor will not be called/executed.


Any thoughts?


Ron



Olly Betts wrote:

> On Fri, Oct 19, 2007 at 02:15:52AM +0200, Ron Kass wrote:
>   
>> You can replace the line with a [my $Xapian_DB = 
>> Search::Xapian::Database->new("test");] if you already have a test 
>> database in place. Same error.
>>     
>
> I used this variant.
>
>   
>> Notice that the bug happens on the SECOND call to a thread instance. It 
>> can be a call to the detach method [->detach();].. same error.
>>     
>
> If you move the creation of the database down a line or two, the SEGV
> happens on the third thread.  If you move it down below the creation of
> the threads, the code runs to completion.  This seems a reasonable
> workaround as you can't share a Xapian object between threads anyway.
>
> Now `perldoc threads' says that the Perl threads module starts a new
> interpreter instance for each thread, and that variables aren't shared.
> However, adding a printf to the XS wrapper for the Database destructor
> shows it is called when each thread terminates!
>
> If I add `print "$Xapian_DB\n"' to each thread routine, the output is:
>
>     1
>     Search::Xapian::Database=SCALAR(0x954a70)
>     joins #1
>     2
>     Search::Xapian::Database=SCALAR(0xaffcd0)
>     Database dtor called
>     joins #2
>     Database dtor called
>     Segmentation fault (core dumped)
>
> So it looks like the new interpreter for each thread makes a new Perl
> Search::Xapian::Database object, but wrapped around the same C++
> Xapian::Database object inside.  That's never going to work well!
>
> I've no idea how to fix this (or if it is fixable even), but you have a
> workaround.
>
> Cheers,
>     Olly
>