pid_t or Q_PID?

[David Faure]

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 at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).