Mailing-List: contact lucy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Wed, 9 Nov 2011 10:41:53 -0800
From: Marvin Humphrey <marvin@rectangular.com>
To: lucy-user@incubator.apache.org
Message-ID: <20111109184153.GA8863@rectangular.com>
References: 
 <CAKn6EF9RB96LUw2yMux_k+68BRVWLk_tYtZnpCLJN19QpCLeNA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAKn6EF9RB96LUw2yMux_k+68BRVWLk_tYtZnpCLJN19QpCLeNA@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [lucy-user] LucyX::Remote::SearchServer concurrency

On Wed, Nov 09, 2011 at 08:33:31PM +0200, goran kent wrote:
> Looking at the code (and I'm no Perl guru) for
> LucyX::Remote::SearchServer->serve(), I don't see any forking or other
> multitasking mechanisms being used.  Correct me if I'm miss-reading
> the code, but doesn't that mean that serve() will block until it
> finishes the current search  --  ie, no concurrent searches?

Yes.

FWIW, Searchers are cheap, because we rely heavily on the OS cache rather than
dump stuff into process RAM.  That aids with multi-process concurrency,
because adding another worker is inexpensive.

Marvin Humphrey