pid_t or Q_PID?

[Simon Hausmann]

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.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070614/023453cc/attachment.sig>