Needing a QEventLoop for a kioslave
Ingo Klöcker
kloecker at kde.org
Wed Feb 11 19:23:19 GMT 2009
On Wednesday 11 February 2009, Thiago Macieira wrote:
> Friedrich W. H. Kossebau wrote:
> >What to do then with static QObjects created by K_GLOBAL_STATIC
> > inside the 3-party code? It is said all QObject created in the
> > thread have to be deleted before the thread ends. So if I wrap the
> > execution of the non-gui (KDE) library code in a thread not the
> > main
> > QCoreApplication::exec() one, can/will K_GLOBAL_STATIC bind them to
> > the thread somehow?
>
> Well, you're out of luck. You can ask the 3rd-party developer to make
> his library thread-safe.
>
> A global static QObject means it's not thread-safe. Like the GUI
> parts of Qt. But ioslaves aren't GUI-enabled, so asking for
> thread-safety is reasonable.
>
> A side note: QObject classes in global statics is a bad idea,
> regardless of how many threads you're actually using. Keeping
> QObjects alive past QCoreApplication's demise will cause all sorts of
> havoc with the internal QThreadData (it's only deleted when the last
> QObject is deleted), which in turn may cause problems for properly
> disposing of QThreadStorage objects.
>
> Also note that destructors of global-static objects have to be
> *extremely* careful, because many subsystems may already be shut
> down, like the Local8Bit conversion in QString.
I guess that can be remedied by destroying the global statics with a
clean-up function (registered with qAddPostRoutine), though, according
to the API docs of qAddPostRoutine, it might not be the best method to
remedy this problem.
BTW, the API docs of qAddPostRoutine state that the clean-up functions
will be called by ~QApplication(). A quick look at the code shows that
they will also be called by ~QCoreApplication(). This should probably
be clarified in the API docs.
Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090211/1ca01061/attachment.sig>
More information about the kde-core-devel
mailing list