[KinoSearch] kinosearch and a mod perl web-app

Marvin Humphrey marvin at rectangular.com
Thu Oct 19 15:46:29 PDT 2006




On Oct 19, 2006, at 2:49 PM, Dan Chicot wrote:

> My guess is that the problem occurs when 2 threads use the searcher  
> simultaneously.  So, I suppose my question is: Should I be taking  
> steps to lock the searcher prior to use?

That seems likely.  KinoSearch is not thread-safe.  I've tried to  
make it fail sanely by making CLONE a fatal method for all KinoSearch  
classes:

slothbear:~/perltest marvin$ cat thread_is_dead.plx
#!/usr/bin/perl
use strict;
use warnings;

use threads;
use KinoSearch::Analysis::Tokenizer;
my $t =  KinoSearch::Analysis::Tokenizer->new;
my $thread = threads->create('do_stuff');
sub do_stuff { sleep 1 }

slothbear:~/perltest marvin$ perl thread_is_dead.plx
CLONE invoked by package 'KinoSearch::Util::CClass', indicating that  
threads or Win32 fork were initiated, but KinoSearch is not thread- 
safe at /Library/Perl/5.8.6/darwin-thread-multi-2level/KinoSearch/ 
Util/Class.pm line 97.
slothbear:~/perltest marvin$

Looking at the stack trace, it's FieldsReader::fetch_raw() that's  
throwing the innermost Perl error.  FieldsReader objects live inside  
IndexReader objects, which live inside Searcher objects.  If a  
FieldsReader gets out of sync and thinks its reading one part of the  
index when its actually reading another, you'd likely get an error  
like the one you got, or possibly garbage if you were really unlucky.

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/



_______________________________________________
KinoSearch mailing list
KinoSearch at rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch




More information about the kinosearch mailing list