KProcess overhaul

[Oswald Buddenhagen]

On Sat, Apr 15, 2006 at 10:33:26PM +0200, Ralf Habacker wrote:
> Matt Rogers schrieb:
> >On Saturday 15 April 2006 12:21, Oswald Buddenhagen wrote:
> >>On Sat, Apr 15, 2006 at 07:13:45PM +0200, Ralf Habacker wrote:
> >>    
> >>>As far as I understood, are pipes already used on unix to communicate
> >>>between parent and child process
> >>>      
> >>>for example to detect child process termination,
> >>>      
> >>not really.
> >>    
> You mean closing of the pipe indicate process termination.
>
no. i mean, one *might* do so, but generally it is a bad idea.
process termination is signalled by the kernel with SIGCHLD and handled
by the program with wait().
what the process does to convey the information from the signal handler
to the main loop is a different concern and totally irrelevant in this
context.

> >>>to receive stdin and to send stdout/stderr data.
> >>>      
> >>yes. on windows not?
> >>    
> on windows too.
>
good

> I 'm trying to understand the difference to pty. :-)
>
once both ends are open, there is no difference QProcess would have to
bother with. i just assume windows does not have such a thing. :)

> >Aren't file descriptors *nix specific? If they are, that could be why 
> >they're against it.
> >  
> Windows uses file handles in the basic api.  file descriptor are handled 
> on the runtime library level. 
> 
misunderstanding alert ...
file descriptor == file handle in kernel terminology.
file pointer is what you mean with file descriptor. that's an ansi c
construct, and of course it exists on unix as well.
QFile can use both file handles and file pointers, depending on an
option to open(). on unix this generally does not hurt, as the FILE api
provides fileno(), which returns the underlying file handle which is
important for redirection purposes. i suppose the same is true on
windows. however, if on OS X FILEs are built on top of a different
kernel interface, there is a serious problem regarding redirection,
obviously.

> A major difference to unix is that the network api and the file api does 
> not have the same type of handles.  As example you cannot use the same 
> write() function on c level for sockets and for files. You have to check 
> by yourself if a handle is a socket or a file handle and then to select 
> the required function  :-( 
> 
i know ... minix was there some 20 years ago, iirc. :)
i suppose that also means one cannot redirect a standard io handle to a
network socket - another asymmetry, but hey ...

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