| Subject: | output_fh(, redefined \*STDOUT ) stops output after several kilobytes |
| Date: | Wed, 3 Feb 2010 12:25:09 +0400 |
| To: | bug-XML-LibXSLT [...] rt.cpan.org |
| From: | Peter Vereshagin <peter [...] vereshagin.org> |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Be sure to wear flowers on your hat, bug-XML-LibXSLT!
I hace trouble with v1.68 from the freebsd ports. I have no problem with terminal's STDOUT, only with CGI::Fast' s redefined STDOUT ( and STDERR, too ):
===
#!/usr/bin/perl -w
use strict;
use warnings;
BEGIN{
$ENV{FCGI_SOCKET_PATH} = "/tmp/spawner.sock";
}
use CGI::Fast;
use XML::LibXSLT;
my $xslt = XML::LibXSLT->new;
chown( 20010, 20020, $ENV{FCGI_SOCKET_PATH} ) or die $!;
chmod( 0660, $ENV{FCGI_SOCKET_PATH} ) or die $!;
while( my $fcgi = new CGI::Fast ) {
my $sheet = $xslt->parse_stylesheet_file( '/path/file.xsl');
print "Content-type: text/plain\n\n";
$sheet->output_fh( $sheet->transform( XML::LibXML->new->parse_string( '<main />' ) ), \*STDOUT ) or die $!;
}
===
the file.xsl is:
===
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:strip-space elements="td th" />
<xsl:template match="/">
<html>
000 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234
[...]
299 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234
</html>
</xsl:template>
</xsl:stylesheet>
===
I don't get its output to the end of the stylesheet with diagnostics on nginx's error log:
===
2010/02/03 12:01:46 [error] 1647#0: *22 FastCGI sent in stderr: "print to fh failed at /usr/local/lib/perl5/site_perl/5.8.9/mach/XML/LibXSLT.pm line 477" while reading upstream, client: 127.0.0.1, server: skybill.box, request: "GET / HTTP/1.0", upstream: "fastcgi://unix:/tmp/spawner.sock:", host: "skybill", referrer: "vereshagin.org"
===
Browser gets the start of the output.
There is no such a trouble with XML::LibXML's ->toFH().
The current workaround is: print ->output() which is the lack of efficiency.
Looks like an I/O buffers race/block condition to me. But it's all about C code which I'm not a master of.
Same happens with STDERR appears instead STDOUT on that example:
===
2010/02/03 12:03:43 [error] 1648#0: *29 FastCGI sent in stderr: "1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234
[...]
151 012345678" while reading response header from upstream, client: 127.0.0.1, server: skybill.box, request: "GET / HTTP/1.0", upstream: "fastcgi://unix:/tmp/spawner.sock:", host: "skybill", referrer: "vereshagin.org"
===
Thank you.
73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB 12F8 0CE1 4AAC A0E2 6627)
- --
http://vereshagin.org
-----BEGIN PGP SIGNATURE-----
Version: Vereshagin v2.0.10 (CP/M)
iEYEARECAAYFAktpMuMACgkQDOFKrKDiZieFhACfcvnd6ogFOu+ep5IUXm3CH2s3
N3MAn3aGGhN7SRQPdrPIjUurS64As3Qk
=6NV/
-----END PGP SIGNATURE-----