[bt-devel] Bookshelf manager bugs
Eeli Kaikkonen
eekaikko at mail.student.oulu.fi
Sat Jan 10 13:59:55 MST 2009
Thanks for comments!
Joachim Ansorg wrote:
> I think we can't assume that Sword's SWMgr is reentrant or thread-safe.
> Thus it's better to synchronize the access to Sword with a Mutex
> (http://doc.trolltech.com/4.4/qmutex.html).
> Even though you create a separate SWMgr for each thread it doesn't mean it's
> thread safe. SWMgr could access shared data for example.
Yes. There are some internal comments in the sword library source that
give the impression that it's meant to be thread safe, but we cant' be sure.
>
> With a single core cpu not-thread-safe code doesn't show the symptoms quickly.
> With two ore more cores the threads are likely to be run concurrently and this
> shows the bugs more quickly.
>
> Unless you are sure that SWMgr is thread safe I'd use a QMutex. It needs to be
> shared between the threads to make sure only one thread at a time works with
> Sword at the same time.
> I didn't look into the code if this doesn't break the concurrent installs,
> though.
>
It would inhibit concurrency. It's sword:instmgr:installModule() which
runs the whole install process and takes time. If it's sequenced it's
same as no concurrency.
Threads serve also another purpose, namely non-blocking gui. Therefore
it's not a good idea to remove them. If sword is not thread safe the
solution is to use one install thread at a time. Even that may be unsafe
because the library can be used for other things simultaneously, but I
think the problem is in instmgr. If it's deeper it's a grave bug IMO and
should really be fixed in sword.
--Eeli Kaikkonen
More information about the bt-devel
mailing list