[bt-devel] thread problems
Joachim Ansorg
bt-devel@crosswire.org
Thu, 18 Jan 2001 20:54:29 +0100
Hi!
> > But I don't know if it's possible to use QThreads with pthreads (maybe in
> > Sword). But I'll give it a try.
> > Another problem is that we shouldn't make the backend depend on Qt, but
> > if we use QT threads this dependency is there.
>
> Why not? For speed reasons, ok.
Maybe some other programs will use our backend in future.
But we do also use QString in the backend :(
> > PS: I tested it, it doesn't work. That's why because we use libqt-mt and
> > KDE 2 uses libqt, obviously using the same library in two different
> > versions at one time crashes the program.
> > Sorry.
>
> I do not understand this. Does it mean no application can use QThreads?
> Surely not. There must be some way.
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.
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.
> > Oen the a presenter and the searchdialog for a Bible module without index
> > and search for God.
> > While it's searching change the key in the presenter and you'll get a
> > wrong search result.
>
> A proposal. IMO our problem is that we do the following: (AFAIK)
> -in the beginning a swmgr is created
> -it loads all the available sword modules
> -each one has a separate object
> ->when working with threads, it may be that 2 threads acess members of the
> same module object at 1 time -> wrong result or crash
> ->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 these are just some proposals of one who has no in-depth knowledge.
>
>
> Martin
-- Joachim
BibleTime - www.bibletime.de - info@bibletime.de
BibleTime is an easy to use Bible study tool for KDE / Linux.