--nextPart1226763.MqZE9N4AyO
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 problema=
tic=20
(as you point out) and it's inherently unportable. That's why I don't like =
it=20
in high-level API.

Simon

--nextPart1226763.MqZE9N4AyO
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGcZ7lWXvMThJCpvIRAljOAJ40uxBMA2Ol7LAwzAYpX447KD8HbgCeP4Rb
LHXv1GtC0Zh9ABLuMVziZ78=
=fjkE
-----END PGP SIGNATURE-----

--nextPart1226763.MqZE9N4AyO--