From: Simon Strandgaard <0bz63fz3m1qt3001@...>
Date: 2003-05-15T23:54:34+09:00
Subject: Re: RCR for child execution

On Thu, 15 May 2003 23:27:35 +0900, Mauricio Fern�ndez wrote:

> I think you should read the thread again (I know it's HUGE but that's
> kinda your fault ;-), because this was already suggested and IRC even
> implemented before.

Agree its my fault.. I terrible at software-specifications, therefore most
all this confusion in this thread (sorry again). Thanks to Brian Candler
for summarizing these specs [ruby-talk:71397]. 


> Don't forget this DOES NOT fix the general problem in any way, i.e. it does
> not satisfy all 4 requirements of [ruby-talk:71397] at the same time.
> Please read that post and think on it for a while ;)

Overloading all Rubys output functions does not solve the problem, agree.
But until a "solution" is found I stick with it. I tried this overload
before, but back then I hadn't realized how to treat Kernel#fork and
'system'. Drawbacks (im guessing here): pipe + windows => problems.  

A simple + nice solution is what we are looking for.
 
 
> I know several people have said it already, but I will join my voice to
> theirs to see if it makes a difference:

Great :-)

 
> the general problem cannot be solved without changing UN*X.
> HOWEVER: you can do the stuff with system, backquote and fork and it's
> solving a sizeable part (in fact matz agreed this could be useful if a
> good name was found, and spawn was proposed). BUT this is not what you
> have been *really* asking for from the beginning (1). 
                                         ^^^^^^^^^
Exactly.


> When given this
> option you went for the impossible one (the one that IS really impossible,
> the thing you're doing now was never told to be impossible, and what's
> more, was even suggested to you, but you didn't like it).

When I proposed it I hadn't thought out how implementation of it should
go. I just felt that it would be a 'nice to have' feature.
Therefore I asked the question if it was possible to implement.
And then the discussion just exploated.


> There's no way you can have one part of your process (that in C) with one
> stdout and another with a different one (Ruby). BUT you can make sandboxes
> or ensure that all I/O goes through functions defined by you (but then
> again it's really, really difficult to make them impossible to bypass)
> and that way effectively reach the same end result.

Yes ruby in a sandbox, within the same process as the c++ application.
So that rubys output is 100% seperated from the application.


> (1) the problem is that the requirements expressed in your postings have
> been changing all the time. Everybody kept targeting your "current
> needs", offering solutions and even implementations. 

Again you are absolutely right.. my initial question/proposal was very
loose. [ruby-talk:71397] is exactly what im asking for.


> First you wanted A, then somebody told you had better do B, then you 
> said C would be great but you were rightfully told C was impossible, so 
> better forget about it. 

No. I have only slightly changed opinion.. its still the initial
question/proposal that im wanting. The initial post just needed a bunch of
constraints/conditions [ruby-talk:71397]. Neither more or less :-)


> Then you implement B and say "BTW people said that this was *impossible*".

B is a temporary solution until we find the 'right solution' :-)


--
Simon Strandgaard