[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KProcess overhaul
From:       Oswald Buddenhagen <ossi () kde ! org>
Date:       2006-04-15 12:43:05
Message-ID: 20060415124305.GC7392 () ugly ! local
[Download RAW message or body]

On Sat, Apr 15, 2006 at 01:47:12PM +0200, Ralf Habacker wrote:
> Also after rereading the thread "KProcess overhaul", you have started 
> I'm not sure, what you exactly means with this. Seems we have to collect 
> the requirement for the planned KProcess. I mean KProcess should have 
> the following functionality or speeking in use cases:
> 
> 1. it should be able to start child process in blocking an non blocking 
> mode
> 2. it should be possible to provide the child process with specific  
> command line arguments and a specific environment
> 3. it should be able to set the working directory of the started child 
> process
> 4. it should be able to send data to the child process stdin
> 5. it should be able to get data from the child process stdout and stderr
> 6. it should be able to terminate child processes
> 7. it should be able to get a signal on child process termination
> 
8. it should be able to connect multiple processes with each other,
without the parent process being involved past the process creation.
mkisofs|cdrecord type of things, you know.
9. on unix, it should be able to deal with ptys
10. it should be able to do arbitrary redirections without overhead,
which is just a generalisation of 8 & 9.

> >>   3. Who will write the doc ? (I'm currently not very familar with KDE 
> >>doc writing, I can write examples as shown  below)
> >>
> >>    
> >doc? hääää?!? are you stoned?!??!? :)))
> >  
> No ? Isn't any doc/examples required for this new class ? At least the 
> inline documentation has to be written because it will have a different 
> api than K3Process.
>
fix your irony detector, dude. ;)
anyway, the usual apidocs are fine, and if we make only relatively
minor extensions to qprocess, the amount of needed docu will be minimal.

> >>now it is real requred to fix this stuff, because the next major
> >>windows KDE issue - kdeinit and kioslave loading are waiting for a
> >>solution.
> >>
> >>    
> >yeah - tell tt.
> >  
> over which communication channel ?
>
supposedly over thiago, who promised to kick andreas harder.

> >to sum it up, i think you can do the following without potentially
> >wasting work:
> >- move kprocess/kprocio to kde3support
> >  
> what about KProcessController, K3Process requires it
> 
that's just an internal class. obviously, it has to move as well.

> and KApplication also, so kde3support have to be included by kdecore.
>
apply the attached patch (can't test quickly myself, have no kde4 build).

> >- create class KProcess : public QProcess and implement everything you
> >  need that can be *cleanly* implemented on top of existing
> >  functionality - 
> there is nothing else required for windows at now.
>
then you can #define KProcess QProcess for now. :)

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

["_procref.diff" (text/plain)]

Index: kprocctrl.cpp
===================================================================
--- kprocctrl.cpp	(revision 530108)
+++ kprocctrl.cpp	(working copy)
@@ -134,7 +134,19 @@
   handlerSet = false;
 
 #ifdef Q_OS_UNIX
-  sigaction( SIGCHLD, &oldChildHandlerData, 0 );
+  struct sigset_t mask, omask;
+  sigemptyset( &mask );
+  sigaddset( &mask, SIGCHLD );
+  sigprocmask( SIG_BLOCK, &mask, &omask );
+
+  struct sigaction act;
+  sigaction( SIGCHLD, &oldChildHandlerData, &act );
+  if (act.sa_handler != theReaper) {
+     sigaction( SIGCHLD, &act, 0 );
+     handlerSet = true;
+  }
+
+  sigprocmask( SIG_SETMASK, &omask, 0 );
 #else
   //TODO: win32
 #endif
Index: kapplication.cpp
===================================================================
--- kapplication.cpp	(revision 530108)
+++ kapplication.cpp	(working copy)
@@ -95,8 +95,6 @@
 #include <netwm.h>
 #endif
 
-#include "kprocctrl.h"
-
 #ifdef HAVE_PATHS_H
 #include <paths.h>
 #endif
@@ -551,8 +549,6 @@
      ::exit(127);
   }
 
-  KProcessController::ref();
-
   (void) KClipboardSynchronizer::self();
 
   QApplication::setDesktopSettingsAware( false );
@@ -1157,8 +1153,6 @@
 
   delete smw;
 
-  KProcessController::deref();
-
 #ifdef Q_WS_X11
   if ( d->oldXErrorHandler != NULL )
       XSetErrorHandler( d->oldXErrorHandler );


[prev in list] [next in list] [prev in thread] [next in thread]