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

List:       kde-core-devel
Subject:    Re: pid_t or Q_PID?
From:       David Faure <faure () kde ! org>
Date:       2007-06-14 22:17:37
Message-ID: 200706150017.38119.faure () kde ! org
[Download RAW message or body]

On Thursday 14 June 2007, Simon Hausmann wrote:
> On Thursday 14 June 2007 21:12:26 Oswald Buddenhagen wrote:
> > On Thu, Jun 14, 2007 at 08:56:28PM +0200, Simon Hausmann wrote:
> > > I still see the risk that if we continue to return a pid_t or a qint64
> > > in a high-level API like KRun or KToolInvocation people are likely to
> > > write code that actually uses that handle with Posix APIs like
> > > wait(2). As a result it just means more work for Christian and other
> > > win32 porters. I don't think we should make it _that_ easy to write
> > > unportable code.
> >
> > to be clear: i want the win32 pid, not the handle, i.e., the code you
> > suggested, only already in KProcess (so KRun just pipes it through).
> > nobody is going to wait() on it, as this won't work anyway
> > (startDetached() ...). and doing anything but logging/displaying the pid
> > is not possible, either, as the process is detached and thus any active
> > manipulation of the process is inherently racy. so far the theory at
> > least ...
> 
> Yes, so what's the point of exposing the pid? Code that uses it is problematic 
> (as you point out) and it's inherently unportable. That's why I don't like it 
> in high-level API.

I believe it's used for startup notification purposes.

Nothing to do with wait().

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
[prev in list] [next in list] [prev in thread] [next in thread]