[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