[kepler-dev] RE: Combining the CommandLine and Exec actors
Ilkay Altintas
altintas at sdsc.edu
Sun Aug 8 22:03:22 PDT 2004
Thanks Dan! These are really good and helpful suggestions.
Especially the items 6 and 7 sounds very interesting.
I would like to discuss these with you in detail before I
update the CommandLine actor as you've used both actors.
Thanks again for sharing this comparison.
Talk to you soon on this,
Ilkay
> -----Original Message-----
> From: Dan Higgins [mailto:higgins at nceas.ucsb.edu]
> Sent: Sunday, August 08, 2004 2:57 PM
> To: Ilkay Altintas; kepler-dev at ecoinformatics.org
> Subject: Combining the CommandLine and Exec actors
>
>
> Ilkay,
> On Friday on IRC, you mentioned the possibility of combining the
> CommandLine and Exec actors. I thought I would just write down some
> thoughts on that idea.
>
> 1) The two actors are similar enough that combining them is probably a
> good idea. There are some subtle differences, however, that I am not
> sure I fully understand.
>
> 2) The CommandLine actor uses the OS-specific commandline shell program
> for launching files ('cmd.exe' on WindowsXP, 'sh' on Unix machines) to
> launch a process. This allows the use of all features that one can put
> on a command line, including the use of file based io redirection (e.g.
> 'program < infile >outfile'). Currently there is not an input stream
> port for data being sent to the process being launched (but there can be
> an input file), but there is an output port.
>
> 3) The Exec actor does not use the the commandline executable, but
> rather launches a subprocess directly with support for input/streams
> being directly connected. Command line redirection to/from files cannot
> be done with this approach, although the whole thing is simpler because
> it doesn't involve an intermediate program (the shell) to run the
> subprocess. The Exec actor also has special threads for grabbing io
> streams (and I believe these are needed, at times, on Windows).
>
> 4) Both the CommandLine and Exec actors wait for the subprocess to
> complete. The InteractiveExec actor is an attempt to let the underlying
> subprocess continue operating and thus avoid repeated code startup
> delays. It still has some problems with when to shut down the subprocess.
>
> 5) Simply adding an input stream to the CommandLine actor would make it
> quite similar to the Exec actor. There would be some confusion about
> what the presence of both inputFileHandle and input stream parameters
> might mean. [I am not sure what it means to tell the commandline shell
> to use standard input AND redirect the input from a file ? --- And I
> assume the actor would send info from an input to the commandline shell
> which would forward it to the program that it launched?] I would guess
> that if the stream io connections were added to CommandLine, we should
> also use the stream grabber threads that seem to be needed for Windows.
>
> 6) Should we add a parameter to allow the subprocess that is launched to
> return without completing? (i.e. continue to run) This could be quite
> useful with some processes (like R) to avoid reloading code and for
> showing displays created by the subprocess. The process would be created
> on the first 'fire' event, and we would have to figure out how to
> reliably shut it down later.
>
> 7) Also note that the Exec actor has some 'expert' parameters that allow
> for setting execution directories and environment variables for the
> subprocess being launched. These could be useful at times and should
> probably be included.
>
> Questions and Comments appreciated.
>
> Dan Higgins
> NCEAS
>
More information about the Kepler-dev
mailing list