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

[Ron Kass]

Yes. This solved the problem.
This makes Xapian thread-safe.
Adding the directive below forces threads to NOT clone the object, which 
in turn eliminates the destructor's call that you saw.
    |sub CLONE_SKIP { 1 }

Note that that since the object is not cloned, threads can not use the 
object (naturally).
If we wanted to really make the object thread-safe AND thread-aware, we 
would actually clone it BUT also make it aware of its scope.
First we would need to see that Xapian's core supports multi-threading 
properly and that it works well from the children threads.
Second, while reading can be done from multiple objects, writing can not 
- correct me if I'm wrong. So while we COULD clone new ||Database 
||objects for children threads, we must not do so for WritableDatabase. 
In such a case, we would just use the parent object, but keep a count of 
the number of instantiations it had and only destroy it if all 
references to the object were released (upon destruction). This can be 
done with Semaphores for example.

But as a quick and simple way to solve the it in a thread-safe manner, 
adding the CLONE_SKIP directive to the top of the objects class files 
works perfectly.

(maybe you will consider this, or rather the more elaborate 
implementation for future revisions?)

Best regards,
Ron

|
> On Fri, Oct 19, 2007 at 05:54:07AM +0200, Ron Kass wrote:
>   
>> Perl after 5.8.7 has support for the |CLONE_SKIP| special subroutine. 
>> Like |CLONE|, |CLONE_SKIP| is called once per package; however, it is 
>> called just before cloning starts, and in the context of the parent 
>> thread. If it returns a true value, then no objects of that class will 
>> be cloned; or rather, they will be copied as unblessed, undef values. 
>> This provides a simple mechanism for making a module threadsafe; just 
>> add |sub CLONE_SKIP { 1 }| at the top of the class, and |DESTROY()| will 
>> be now only be called once per object. Of course, if the child thread 
>> needs to make use of the objects, then a more sophisticated approach is 
>> needed.
>>
>> Your thoughts?
>>     
>
> Does doing as that suggests solve your problem?
>
> Cheers,
>     Olly
>