On Thu, Nov 09, 2006 at 02:12:10PM +0100, Peter Lundblad wrote:
> > Actually solving the problem would require us to be able to exec()
> > commands with stdin/out/err connected to non-file-handle-backed streams.
> > Of course, that's impossible.
> >
> No, we don't need that. We could use pipes and forward to our own stream
> objects if we want to.
>
I think I'm agreeing with you: I meant that we can't literally just
pass streams to be inherited by child processes. What you said above,
I think I said in more detail next:
> > Instead, we'd need to create a temporary file (pipe?) to store the
> > input or output and then connect filehandles to that, marshalling the
> > data to or from the svn_stream_t* to the filehandle as necessary.
> > (We'd also want the ability to detect and extract filehandles from
> > apr_file_t-wrapping-svn_stream_t's, because I suspect we'd want to
> > short-circuit all that nonsense in the usual case).
> >
> Why?
>
Why would we want to special-case the file-wrapping-stream case? Only
because it seems a little mad to use something that provides a pipe to
a pipe reader/stream writer that's wrapping a file handle when we could
instead just provide the file handle directly.
> I don't think it would be too hard, actually. It wouldn't be worth the
> complexity just for this Perl use case, but I think it would improve
> our APIs in general. In general, we should pass streams of data using
> svn_stream_t objects in our APIs rather than files.
>
I completely agree; I just meant that it sounded like a lot of work for
the one specific case.
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Thu Nov 9 18:53:45 2006