[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