Re: Redirectable octave?

[Michael Goffioul]

On 10/15/07, Michael Goffioul <address@hidden> wrote:
> Hi,
>
> I'd like to know whether it would be hard to produce a redirectable octave?
> By redirectable, I mean you could tell octave about the standard
> input/output/error to use and octave would use it for any operations.
> Currently, references to stdin/stdout/stderr and/or 
> std::cin/std::coud/std::cerr
> are present at various locations.
>
> The reason I'm asking about this is because I'd like to embed octave as
> an in-process engine, running in its own thread, with redirected standard IO.
> I know I could theoretically achieve this by redefining std[in|out|err]
> and dup2'ing STD[IN|OUT|ERR]_FILENO, but
> 1) you might not want to redirect standard IO for the whole process
> 2) this seems to be a problem in Win32 (I'm facing a deadlock when one
> thread is reading from stdin (the octave thread) and another is usin shell32
> API).
>
> The reason I'm trying to embed octave as in-process engine and not as
> a separate process with redirected standard IO, is because it allows you to
> integrate the graphical backend with the embedding app.

Maybe my first mail was not clear enough, so let me rephrase it.
I'd like to operate octave in its own thread (within a larger application)
with pipe IO communication (with a terminal emulation at the other
end of the pipes).

In practice, what I'd like to do is the following:
1) create 2 pipes: parentIn/childOut, parentOut/childIn
2) start a new thread
[in the thread function]
3) dlopen octinterp shared lib and get octave_main symbol
4) tell somehow to octave to use childIn/childOut as its "standard" IO
5) run octave_main

The problem is point 4) above: octave uses direct references to standard
input/output at various places (in the form of stdin/stdout or
std::cin/std::cout).
I see 2 cases to achieve point 4):
1) redefine stdin/stdout (and dup2 STDIN_FILENO/STDOUT_FILENO);
however I'd like to avoid that, because this will affect the complete app, while
I just want to affect the octave thread (moreover this seems to be a problem
on Win32 platform)
2) modify octave code such that what octave think is "standard IO" is
configurable. For instance octave_main could have the signature
int octave_main(int argc, char **argv, int embedded, FILE* in, FILE
*out, FILE *err)
and octave would automagically use the given file descriptors for all its IO.
The regular octave executable would just have to call octave_main with stdin,
stdout and stderr.

Is this imaginable? Am I just dreaming?

Michael.