perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <>
Subject Re: [patch] send_fd
Date Sat, 22 Dec 2001 18:42:25 GMT
On Sun, 23 Dec 2001, Stas Bekman wrote:
> That's the thing, we can use sendfile to send files, but not an already 
> opened fh, so I was saying that it doesn't help.

we're going in circles here.  your patch made modperl's send_fd unusable
without a length.  i pointed out there is already sendfile that figures
out length for you.  in other words, why break send_fd to do this:

     open my $fh, $file or return Apache::NOT_FOUND;
+    my $size = -s $file;
+    return Apache::SERVER_ERROR unless $size;

-    my $bytes = $r->send_fd($fh);
+    my $bytes = $r->send_fd($fh, $size);

when you could just do:

> Yes and no. API changes are OK, we can adjust the internals so the Perl 
> interface doesn't change. But if the functionality changes (by removing 
> some things that were available before), there is nothing we can do but 
> implement it ourselves and bearing the resolution of all the portability 
> issues.

in this case, if we need to implement the functionality ourselves, we can
still use apr and perl to take care of portability issues.

> You mean I shouldn't even try to get APR support things like -1 for the 
> input length in send_fd before the API is frozen?

no i don't mean that at all.  you've changed the topic to making the
apache function backwards compatible, something totally different from
your original message with the modperl send_fd patch.

> I think it's quite important to concentrate on implementing things which 
> interface Perl and httpd functionality, so if something is broken or 
> incomplete we can fix/influence. Once 5.8.0 and httpd-2.0 (+apr) get 
> released we are in a lot of trouble if we cannot get all we need from 
> these "libraries" before they are released.

agreed.  i'm not arguing against this.  i was arguing against the original
patch that broke modperl send_fd compat with 1.x.

i wasn't concerned with ap_send_fd because it is so tiny in 2.0 and
not actually used by anything in the core.  my thinking when i added the stub was that if we need something special it would be easier to
craft our own custom function than to debate over ap_send_fd with
new-httpd.  i mean, look at the code for ap_send_fd, there's nothin to
it.  the apr_bucket_file api isn't going to change, neither is the
apr_bucket_pipe api.  those are the important ones for this functionality.
ap_send_fd is just a wrapper, we can make our own that is tuned for modperl.

and there's more than performance to think about here.
think about perlio, PerlIO::gzip for example.  what happens when you do:
open my $gz, "<:gzip", "foo.gz"


works with  pretend ap_send_fd() supports -1 length, it breaks.
granted, this (or tied filehandles of the same nature) would break in 1.x,
but this is something to consider supporting for 2.0.

it could be that send_fd stays as is in and we add a
send_fh() that support everything.  or keep $r->sendfile and add other
methods for sending filehandles that are pipes, or already opened
filehandles with no length, or filehandles that are tied or filehandles
that have custom perlio layers.  i'm in no rush to finalize any of that.
apr already has the apr_bucket_{file,pipe} apis that work very well
for their specific tasks, anything else would need to be customized on our

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message