This sounds good. Some pieces of the code must be rewritten.
I think that SwishOpen must be left as is. In the code of SwishOpen
there can be a call to a new routine, eg:
SwishReadIndexCommonData. This routine may allocate the space
for the common data and cache it. Subsequents calls would get the
On 4 Jun 2001, at 8:51, Bill Moseley wrote:
> At 08:33 AM 06/04/01 -0700, firstname.lastname@example.org wrote:
> >As Bill points, the library is thread/safe for search in 2.1.
> >All the memory allocated in SwishOpen, SwishSearch, etc
> >should be freed in SwishClose. I do not know at this moment
> >if there is any remaining memory leak.
> >But this is not optimal because there are not any shared memory. In
> >other words: If you have 2 threads and both of them opens the same
> >index, the header data of this index is twice in memory although this
> >data is identical.
> I was wondering if a single thread thread could pool and manage open
> indexes (pool handles returned by SwishOpen(), and then share those
> with other threads). But, now I'm not so sure that would work since
> the SWISH structure does get modified during a search.
> I know you can open with SwishOpen() and then run multiple queries,
> but I'm not clear if more than one thread could run queries with the
> same handle at the same time.
> Maybe a threaded application might cache the indexlist, and then when
> a request comes in call SwishOpen() and SwishAttach() so the thread
> get's its own copy of the data structures. Actually, I'm not clear
> where the best optimization would be. Any ideas?
> Bill Moseley
Received on Mon Jun 4 16:39:05 2001