QProcess vs K3Process

[Oswald Buddenhagen]

On Tue, May 29, 2007 at 07:19:25PM +0200, Thiago Macieira wrote:
> Maybe a separate class then? KShellProcess or something similar.
> 
been there, done that, got the t-shirt. k3shellprocess is scheduled for
deletion for years; i'm pondering with deleting it finally.
this is exactly the kind of "feature fragmentation" which made me
sceptical wrt splitting off kptyprocess: suppose you want pty *and*
shell. whoops. i think outsourcing ptys makes more sense ...

> Ok, I see. You want
> 	foo | bar >/dev/null
> 
> And you want to collect stderr from both processes, merged. I see the 
> use-case, but I would argue that it's in fact better to collect them 
> separately. That way, if an error is reported, the application can 
> identify which process did it.
> 
depends on the use case. if timing matters, a common os-level channel is
a must.
this time i *really* attached the mail to tt. (hey, i *did* say that i'm
in a hurry :)

> >the grouping per se is just convenience. you don't want to build a pipe
> >from three processes and start every one, check the errors, handle
> >signals, etc. separately.
> 
> Start every one? Yes, I think you want that. And it isn't difficult 
> anyways, nor is there a particular order in which they must happen. The 
> pipes are created when first needed and the remote end is open when the 
> application starts (either in the parent or in the sibling process).
> 
yes, but why would you *want* to do it separately for every one?

> Check errors, as I said above, it's probably better to detect which object 
> had errors. But you could just connect the signals to the same slots and 
> ignore QObject::sender().
> 
well, the various states are ANDs and ORs, sort of. if the pipe fails,
the caller wouldn't usually care which part failed. and if it would, it
*still* can ask the individual processes.

> >for the os level thing i have a much weaker case. unless somebody wants
> >to implement a shell with qt, no app will need it. however, it is
> >potentially useful for a user - it would be easier to kill off a stuck
> >pipe.
> 
> Why would a pipe get stuck under normal operating conditions?
>
not under normal ones, obviously.

> Besides, if you kill the writing end of a pipe, the reading end gets a
> SIGPIPE. Or EOF.
> 
killing the reading end causes a sigpipe in the writer when the writing
end is written. closing the writing end reads as EOF at the reading end.
but all of this only works if somebody is actually "listening". that's
the same reason why xkill-ing dead apps doesn't always help in
recovering resources.
anyway, as i noted, the case for os-level process groups is really weak;
i won't insist. but KProcessGroup as a convenience class (we want to
keep people away from setUseShell(), right? ;) sure makes sense.

> No, I am not convinced by process groups. For more complex piping 
> mechanisms, maybe. Maybe someone has a valid need for something like:
> 
well, i wouldn't nail it to complexity. even two is too much if you can
have one with relatively little effort in a central place.

> shell: (A | B) 2>&1 >/dev/null | C
> 	A ----stdout---> B --stdout--> /dev/null
> 	  \		  \--stderr--\
> 	   \-----------------stderr-------> C
> 
gimme more. :)

> Or, worse, not possible with shell:
> 	A ----stdout---> B --stdout------> C
> 	  \		  \--stderr--\
> 	   \-----------------stderr------> D
> 
actually, it is possible:
(A|B) 2>&1 >(C) | D
yes, this is bash and needs named pipes. but you get the idea. :)
i don't think one can actually construct a case that is impossible with
bash, but of course it gets really unreadable. but that's not the
question here. maybe somebody wants to start a "playing with the concept
of ipc via pipes" kde-edu project - kbuildpipes or pipekonstruct. :)

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
-------------- next part --------------
An embedded message was scrubbed...
From: Oswald Buddenhagen <ossi at kde.org>
Subject: more on QProcess redirections
Date: Fri, 22 Sep 2006 15:08:31 +0200
Size: 2216
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070529/1f494c7b/attachment.eml>