<div dir="ltr">There may be some solutions，for example<div>class XAPIAN</div><div>{</div><div>    <b>static</b> int InitDatabase();  //for reading only, do not need lock, but if writing use lock</div><div>    int Search(); //safe in one object, do not need lock<br>
};</div><div>XIPIAN xp[ THREAD_NUM ];</div><div><br></div><div>one thread use one object, they use one database.</div><div>these can be in memory with one database.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2014-06-24 20:48 GMT+08:00 Olly Betts <span dir="ltr"><<a href="mailto:olly@survex.com" target="_blank">olly@survex.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Thu, Jun 19, 2014 at 10:52:13PM +0800, Yanxiong Lu wrote:<br>
> Why xapian don't support memory  index/search ?<br>
><br>
> I know there is a method can create memory datebase, like this:<br>
> Xapian::WritableDatabase db(Xapian::InMemory::open());<br>
<br>
</div>While the inmemory backend is handy for some things, in its current<br>
incarnation some operations really aren't very time efficient, and it<br>
doesn't even try to be very space efficient.<br>
<br>
The longer term plan is to replace it, probably sharing code with the<br>
disk based backends (which would make it fairly easy to do neat things<br>
like migrating data from "inmemory" to disk).<br>
<br>
> *But, if i use these in multithread program,  i need create many<br>
> datebases!!*<br>
<div class="">> Xapian::WritableDatabase db1(Xapian::InMemory::open());  //used in thread1<br>
> Xapian::WritableDatabase db2(Xapian::InMemory::open());  //used in thread2<br>
><br>
> because WritableDatabase object isn't thread-safe. And use lock is slowly.<br>
<br>
</div>Pushing those locks inside the Xapian library won't make things any<br>
faster - likely just the opposite.  If the API user locks, they<br>
can choose the granularity, while if Xapian locks, it has to lock<br>
and unlock around every API method called.<br>
<br>
I guess a lock-free, thread-safe inmemory backend implementation might<br>
be possible, but realistically if you want one any time soon, you're<br>
probably going to need to contribute most of the code for it.<br>
<br>
> *So, is there some solutions that One database, many thread can use??*<br>
<br>
The simplest solution currently is probably to create a RAM disk and use<br>
a disk-based backend in it.<br>
<br>
Cheers,<br>
    Olly<br>
</blockquote></div><br></div>