[bt-devel] thread problems

[Martin Gruner]

Hi Joachim,

> Maybe some other programs will use our backend in future.
> But we do also use QString in the backend :(

> No KDE application with kdelibs linked to libqt.so can use the threaded
> libqt-mt.so because this is the same library.
> libqt and libqt-mt would be loaded at the same time.

So how to do it? No way? That would seem rather senseless to me...

> I tracked the search result bug (the 10 items after the first search) down
> to RawText::Search (the part at the end which checks if the result is in
> the scope).
> I changed it a little bit, and as a side effect  searching indexed modules
> is now much faster for large result sets.

I admire you. ;)  Great!

> > ->2 possible solutions:
> >  #1 give an own module object to each presenter, search object,
> >     print object etc.; Problem: possibly huge memory usage
> >     Advantages: sword modules dynamically created, will
> >     only use much memory if you open many modules;
> >     Enables (partly) have sword acess dynamic module
> >     sources like CD-Rom, which are not always available
> >  #2 have sword checking for thread acess, maybe even thread
>
> IMHO no so good, because of the huge memory requirements.
>
> >     sword itself; problem: possibly api change, requires much work
> >     and knowledge
> >     Advantages: sword will be better equipped for the future;
> >     makes threading in client apps easier; less memory usage (Handheld)
> >     (dynamic module checking could be implemented also)
>
> No task for the BibleTime team.
>
> At te moment it works again.

But BT still is not thread-safe, is it? What if I search a module and 
meanwhile modify a presenter showing this module? Is this solution now 
acceptable?

Martin