[bt-devel] thread safety

[Martin Gruner]

> > Now, since we should have bt thread safe before 1.0, we should change the
> > architecture. Every presenter, the searchdialog and the groupmanager will
> > get their own modules. Thats how gnomesword does it; and that should
> > bring the thread safety without flooding the memory.
>
> Are you sure that GnomeSword does it this way?
> I can't find it.

AFAIK in searchstuff.cpp and .h you'll find that the searchdialog has an own 
module. I think they do only search one module at a time.

> > We would have to find some way of storing the key caches somewhere, but
> > that should be possible. We could do it in swordbackend. Swordbackend
> > would no longer contain a list of modules, but rather a list of module
> > names and create a module only if needed. That should be rather easy,
> > cause the existing swordbackend is excellent work.
>
> I don't know if it's so easy because we rely in the frontend on the already
> created modules of the backend.
> All the current code is requiering existing modules and it will surely
> introduce more bugs and problems if we change it.

Maybe.

> All the groupmanager items would get it's own modules objects, each
> presenterw oul get it's own, the searchdialog would get it's own module(s)
> object(s).
> This would eleminate the problem of not being threadsafe, but I'm not so
> sure if it wouldn't require much memory. If we could use less memory why
> should we craete things twice in memory?
> Maybe we could use the copy constructor of SwordModuleInfo to create a new
> copy of the modules used for the searchdialog?

This seems to be a good solution without much work. It does not really make 
bt threadsafe; but since we use only 2 threads (1 for seraching) it should 
work. Let's do it that way.

Martin