On Wed, 07 May 2003 16:10:42 +0000, ahoward wrote:

> On Wed, 7 May 2003, Simon Strandgaard wrote:
> 
>> I embed ruby into C++.  The "void main" is located in the frontend.
>> Right now everything is running in the same process.
>>
>> User supplyed ruby-code is executed in the same process...
>> its NOT executed as a child-process, thus popen3 is not possible.
>> The only thing which is possible right now is the flawed Redirector class
>> technique.
> 
> 
> i've never run the interpreter from c or c++, but it sure seems like it's
> likely that this does an execv, and therefore DOES run in a child process...
> i could be wrong here...

Wrong - No execv here. I embed ruby into c++ almost the same 
way as ruby does itself.. in rubys source see "main.c".  
The ruby code is NOT run in a child process.
Right now its as minimal as possible, everything is in the same
process.

BTW: how do I frequently give time so that ruby can schedule its threads?

 
>> Setting up the redirection will occur within c++!
> 
> then you have ONLY one option, which is to do the equivalent of
> 
>   ruby script.rb 2>&1 > captured
>
> from within c++ unless
> 
>   a) ruby does in fact run in the same process space (not sure about this)
>   b) you want to create a StringIO object from within c++, and point defout and
>   friends at it before executing user ruby code
> 
> because, as i said, i think 'a' is false, you will need to point stderr/stdout
> at a file in c++ before running the ruby interpreter.  i really think this is
> your only option since even if you were able to set up a StringIO, or other,
> object in c++ which could be shared by an in-process ruby - THAT process (the
> ruby interpreter) itself could cause a fork either explicily (fork) or
> implicitly (backticks or system) which would blow your whole StringIO idea out
> of the water.

Yes.. file io works  and might be the only working solution right now.
I am really hoping for a more long term solution to this.

What I don't understand is that capture to a file is working
and that its apparently impossible to capture to a string ???


> in summary i think you have only the option of pointing stderr and stdout at a
> temporary file, running the user's ruby code from the embedded interpreter,
> and then rewinding the file and using that.  however.  i'm with brian that
> it's a bad idea to merge stdout and stderr though - i would point stdout to
> one temp file and stderr to another.  later, you may decide to do one thing
> with the ruby interpreter's stdout and another thing with the stderr.  you may
> always merge them manually if you desire.

Yes its a bad idea to merge stdout with stderr. This was only for
simplicity in my example.  Of cause this has to be seperated.

 

[snip c++ code]
> 
> again, this sure looks like the preparation for a fork/execv - or at least a
> preparation for something which itself might fork/execv ;-)

No its not.  It initializes ruby in the same process as the rest of the
program.


--
Simon Strandgaard