pid_t or Q_PID?

Oswald Buddenhagen ossi at kde.org
Thu Jun 14 20:12:26 BST 2007


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 ...

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.




More information about the kde-core-devel mailing list