Malcolm Rowe writes:
> On Wed, Nov 08, 2006 at 11:39:46AM -0500, David Glasser wrote:
> > On 11/8/06, Malcolm Rowe <email@example.com> wrote:
> So the problem boils down to this:
> - Perl IO memory-backed globs are implemented using the "scalar" PerlIO
> layer, which doesn't make any use of a filehandle (so PerlIO_fileno()
> returns -1).
> - svn_swig_pl_make_file() successfully makes an apr_file_t* that refers
> to a filehandle -1, but then attempting to write anything to that
> handle fails, obviously.
> The solution is probably just to change svn_swig_pl_make_file() so that
> it returns an svn_error_t*, and make it return a sensible error message
> if it sees a PerlIO fileno of -1, because that indicates a
> non-filehandle-backed PerlIO handle that we aren't going to be able to
> wrap in an apr_file_t.
At least that should be done, yes.
> 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.
> 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).
> All that sounds rather.. hard.
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 am not going to work on it, so anyone, feel free if inclined.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Nov 9 14:13:33 2006