octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New function proposal


From: David Bateman
Subject: Re: New function proposal
Date: Tue, 13 Feb 2007 01:24:32 +0100
User-agent: Thunderbird 1.5.0.7 (X11/20060921)

Michael Goffioul wrote:
> David Bateman a écrit :
>> Doesn't the code here effectively do something almost equivalent to
>> popen2? In that case why can't this just be used as a MWVC/MINGW
>> implementation of the popen2 function rather than introduce a new
>> function? If not what is different? Do we need both popen2 and
>> exec_with_pipes?
>>   
> 
> Indeed, exec_with_pipes does the same as popen2. And the logical next
> step was
> to use it in popen2, when the current pipe/fork implementation cannot be
> used.
> I didn't know what as the best way to handle this, as popen2 is m-code
> and exec_with_pipe
> is C++ code. If I wanted to keep popen2 in m-code, I needed at least
> another C++
> function that I could call from popen2; this is exec_with_pipes. Another
> possibility
> was to move the complete popen2 implementation to C++; then you can
> merge both.
> I implemented the first approach.
> 
> A 3rd approach could be to provide octave interface to the required
> building blocks
> I used in exec_with_pipes: this means CreatePipe (~= pipe),
> DuplicateHandle (~= dup2,
> although I'm not sure how handle inheritance is handle by Win32 dup2) and
> CreateProcess (this one would probably need a new function). Then you
> can rewrite
> popen2 in m-code, as it is done with pipe/fork. But this is more work.
> 
> Michael.
> 
> 
> 

Yes, well looking at popen2 and pipe that it call I think they are in
serious need of a rewrite in any case. They both still use deprecated
list objects rather than cell arrays. That being the case probably
option 2 is probably the best..

D.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]