[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-05-28 20:02:34
[Download RAW message or body]

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!

>And btw, why are there missing some values in KProcess::Communication ?
>Using (( KProcess::Communication ) ( KProcess::Stdin | KProcess::Stdout )) as a
>second parameter to the start() call is quite ugly.

IMO, it is WRONG to declare the parameter of start() as KProcess::Communication.
It should be an unsigned since it receives a set of flags. Of course, that's
not your fault. Until somebody cleans that up, you'll have to use that ugly
construction.

-- Hannes

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