[bt-devel] thread problems

[Martin Gruner]

> 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.

> 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.

> > For sword I don't know what should be done. I once asled on sword-devel,
> > but nobody knew wether sword really _is_ thread safe. How can you find
> > out if a program is thread safe, and how can you make it thread safe?
>
> I don't know how to find it out, and my knowledge of threads is too bad to
> make Sword thread-safe.
> If we make sure no variables are read and written at the same time and if
> we make sure no files are read at the same time it's thread safe.
>
> IMHO Sword is _not_ thread safe. To explain this here's a small experiment:
>
> 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 
    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)

But these are just some proposals of one who has no in-depth knowledge.


Martin