[Marble-devel] Fix for Ugly: Marble Runners

Henry de Valence hdevalence at gmail.com
Sat Jul 11 05:25:38 CEST 2009


Since the Marble Runner code is exceptionally poor and ugly -- clearly, it was 
written by some kind of idiot like myself [:P] -- I've been trying to refactor 
it a bit.

Basically what this entails is that MarbleAbstractRunner will now derive 
QRunnable, and runners will call threadsafe methods of the runner manager to 
return the data. It all works great, except that there is a problem with 
networked runners. 

The ONF (Openstreetmap Name Finder) runner -- which is, frankly, pretty 
terrible at searching, but that's a different issue -- needs to access the 
network. To do this I modified HttpDownloadManager to be threadsafe, so that it 
can be shared between all of the runners.*

The problem lies with the fact the HttpDownloadManager provides async 
downloading. Thus the run() function of the QRunnable will exit before it 
finishes. By default, QRunnables are deleted when they finish run(). This can be 
changed so that ownership is kept by the creator of the QRunnable.

The way that occurred to me to get around this is to have the ONF runner also 
inherit QObject and have a slot called when the download finishes that returns 
the results and then does
delete this;
which seemed like a clever way to do it. But, this reminded me of similarly 
"clever" things that go on in the current implementation, so I thought I'd ask 
the ML for some advice on this.

Henry de Valence

* I think my patch works; I've thought through all of the public methods and 
they're all protected by mutex lockers. But I am suspicious of "friend class 
HttpJob". If HttpJob accesses HttpDownloadManager's privates, there will be a 
great deal of awkwardness with my patch.


More information about the Marble-devel mailing list