pid_t or Q_PID?

[Christian Ehrlicher]

Simon Hausmann schrieb:
> On Thursday 14 June 2007 07:54:58 Thiago Macieira wrote:
>> Christian Ehrlicher wrote:
>>> Hi,
>>>
>>> while porting krun from k3process -> kprocess I hit the problem then
>>> QProcess is using Q_PID instead pid_t. Therefore my question - what to
>>> use in the interface of krun?
>> Portable code shouldn't have to know the PID. Q_PID is a handle on
>> Windows, AFAIR.
> 
> Unfortunately QProcess::pid() on Windows returns a pointer to a 
> PROCESS_INFORMATION structure that is owned by QProcess while on the other 
> platforms it returns a plain qint64.
> 
> My preferred option is to change the return type of KRun::run() to return void 
> and remove the pid as out argument from KToolInvocation instead using pid_t. 
> But if that is no option then I suggest to change it to return a qint64 and 
> have an #ifdef in the implementation:
> 
> #if defined(Q_OS_WIN)
>     return process->pid()->dwProcessId;
> #else
>     return process->pid();
> #endif
> 
Ok, I think we should return at least bool so that the caller can 
determine if the process was started or not (I found one place with lxr 
where the return value was checked)

If there are no objections against, we'll change this next monday.
Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070614/36e26398/attachment.sig>