Hi David
Hmmm. I was wondering about the influence of Capture::Tiny, but didn't
think enough about its internals.
I will (just this once) be delighted to zap it :-).
I'll email Alex directly rather than releasing another version.
$many x $thanx;
On 30/08/13 09:48, David Golden wrote:
From perlfork:
* In certain cases, the OS-level handles created by the pipe(),
socket(), and accept() operators are apparently not duplicated
accurately in pseudo-processes. This only happens in some
situations, but where it does happen, it may result in deadlocks
between the read and write ends of pipe handles, or inability to
send or receive data across socket handles.
Hard to say if that's the problem, but I'm always wary of code that
uses fork() on Windows.
I would try taking Capture::Tiny out of the mix. I don't know why it
would be a problem, but you've got a lot of handle manipulation going
on before the capture runs and maybe something is getting lost there.
Run with qx() and see if you get anything. If so, then it's
Capture::Tiny. If not, then it's fork/pipe on Windows.
David
On Thu, Aug 29, 2013 at 7:20 PM, Ron Savage <r...@savage.net.au> wrote:
Hi
I'm using this code in the tests for CGI::Snapp, with pre-reqs:
'Capture::Tiny' => 0.22,
'Carp' => 1.20,
'CGI' => 3.63,
'CGI::PSGI' => 0.15,
'CGI::Simple' => 1.113,
'Class::ISA' => 0.36,
'Data::Dumper::Concise' => 2.020,
'File::Spec' => 3.40,
'Hash::FieldHash' => 0.14,
'IO::Pipe' => 1.14,
'Log::Handler' => 0.78,
'parent' => 0.225,
'Proc::Fork' => 0.802,
'strict' => 1.03,
'Try::Tiny' => 0.16,
'vars' => 1.01,
'warnings' => 1.03,
sub run_script
{
my($self, $script) = @_;
my($pipe) = IO::Pipe -> new;
my(@stack);
run_fork
{
parent
{
my($child) = @_;
waitpid $child, 0;
$pipe -> reader;
push @stack, $_ while <$pipe>;
}
child
{
my($stdout, $stderr, @result) = capture{system($^X,
$script)};
$pipe -> writer;
print $pipe $stdout;
exit;
}
error
{
croak "Testing script $script\n";
}
};
return [@stack];
} # End of run_script;
Here's some output reported by Alexandr Ciornii
# Running basic.pl
not ok 1 - run() in basic.pl returned real data
# Failed test 'run() in basic.pl returned real data'
# at t/test.t line 17.
not ok 2 - basic.pl ran 0 tests
# Failed test 'basic.pl ran 0 tests'
# at t/test.t line 31.
# got: '0'
# expected: '4'
# Running callbacks.pl
not ok 3 - run() in callbacks.pl returned real data
# Failed test 'run() in callbacks.pl returned real data'
# at t/test.t line 17.
not ok 4 - callbacks.pl ran 0 tests
# Failed test 'callbacks.pl ran 0 tests'
# at t/test.t line 31.
# got: '0'
# expected: '13'
# Running defaults.pl
not ok 5 - run() in defaults.pl returned real data
# Failed test 'run() in defaults.pl returned real data'
# at t/test.t line 17.
not ok 6 - defaults.pl ran 0 tests
# Failed test 'defaults.pl ran 0 tests'
# at t/test.t line 31.
# got: '0'
# expected: '6'
# Running headers.pl
not ok 7 - run() in headers.pl returned real data
# Failed test 'run() in headers.pl returned real data'
# at t/test.t line 17.
not ok 8 - headers.pl ran 0 tests
# Failed test 'headers.pl ran 0 tests'
# at t/test.t line 31.
# got: '0'
# expected: '17'
# Running hook.tests.pl
(hangs)
The counts got/expected are lines of output. Can't explain that problem
either, but the hang is worse.
Any ideas?
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
--
Ron Savage
http://savage.net.au/
Ph: 0421 920 622
