[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