[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: little KProcess problem
From:       Johannes Sixt <Johannes.Sixt () telecom ! at>
Date:       1999-06-01 20:41:27
[Download RAW message or body]

On Tue, 01 Jun 1999, Lubos Lunak wrote:
>On Pá, 28 kvě 1999, Johannes Sixt wrote :
>>On Fri, 28 May 1999, Lubos Lunak wrote:
>>>Hello,
>>>
>>>I'm now writing non-blocking gethostbyname() for KBiff. While the multithreaded
>>>version was piece of cake, fork()-ing drives me nutts. KProcess helped quite a
>>>lot and it's almost done already, but it causes another problem : I have all
>>>KProcesses in my class in a static QList, and if some of them are still running
>>>while I quit the app, it segfaults. The reason is that KProcessController is
>>>destroyed in ~KApplication() and it's called before the destructor of my list.
>>>Could it be changed that it will be destroyed later, at least in 2.0 libs (
>>>I'll have to do some workaround for it now anyway ) ? Using atexit() is the
>>>best way of handling deleting of such global data I'm aware of, though there
>>>still may be some problems. Or is there a better way of doing this ?
>>
>>Derive a class from KApplication and empty the QList in its destructor. (And
>>kill away the still running children also!)
>>
>>Think about it: Your application is terminating. The destructor of the
>>KApplication-derived class is the right way to clean up. Of course, you should
>>only remove the QList entries, the QList object itself will be destroyed later,
>>but that doesn't hurt since it will be empty by that time!
>
>Ok, I know I can do this ( and it looks like I'll have to ), but I don't like it
>much this way. The classes for the gethostbyname() stuff are KBiff-independent,
>so I'd prefer atexit()-ing it or being able to get a function called when
>KApplication gets destroyed without calling it explicitly in KMyWhateverApp
>destructor whenever it's used.

atexit() doesn't help since the registered function is called only after
KApplication gets destroyed, which leaves you where you have begun. :-(

BTW, you instead of KApp's shutdown signal you can use its destroyed() signal
(or whatsitcalled, see QObject). No, wait, it doesn't help either, because it is
also called only after KApplication::~KApplication :-(

-- Hannes

[prev in list] [next in list] [prev in thread] [next in thread]