Testing signal handlers

[Leopold Toetsch]

I've a slight problem when it comes to testing signal handlers. This is
currently enabled on linux only.

The attached t/pmc/signal.t should send a SIGINT to a sleeping or
looping PASM test. This basically works, but the test output looks a bit
ugly:

t/pmc/signal............# No tests run!
t/pmc/signal............ok 1/2# Looks like you planned 2 tests but only
ran 1.
t/pmc/signal............ok

It seems, that due to the fork, the test system is getting an empty test
result too.

$ perl -Ilib t/pmc/signal.t
1..2
# No tests run!
ok 1 - SIGINT event - sleep
# Looks like you planned 2 tests but only ran 1.
ok 2 - SIGINT event - loop

Perl and test hackers please help,
leo

[Uri Guttman]

>>>>> "LT" == Leopold Toetsch <l...@toetsch.at> writes:

LT> The attached t/pmc/signal.t should send a SIGINT to a sleeping or
LT> looping PASM test. This basically works, but the test output looks a
LT> bit ugly:

LT> t/pmc/signal............# No tests run!
LT> t/pmc/signal............ok 1/2# Looks like you planned 2 tests but
LT> only ran 1.
LT> t/pmc/signal............ok

LT> It seems, that due to the fork, the test system is getting an empty
LT> test result too.

Test::* can't handle output from forked children (it traps redirect
STDOUT in the current process so it has no access to STDOUT of a
child). this is a known problem. there are several ways around it. one,
have the child signal the parent which can then report test
results. two, have the child send data back to the parent (via a pipe or
even a temp file) and then have the parent report results. you can also
signal yourself and not need a child. i have a test script for event
loops that works in a single process (it uses a socketpair to test i/o
events). i can send it to you if you want. obviously it will need major
changes to test parrot but the overall setup and test stuff should be
useful to you.

uri

--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

[Boris Sukholitko]

Hi,

On Tue, Jan 27, 2004 at 12:49:25PM -0500, Uri Guttman wrote:
> >>>>> "LT" == Leopold Toetsch <l...@toetsch.at> writes:
>
> LT> The attached t/pmc/signal.t should send a SIGINT to a sleeping or
> LT> looping PASM test. This basically works, but the test output looks a
> LT> bit ugly:
>
> LT> t/pmc/signal............# No tests run!
> LT> t/pmc/signal............ok 1/2# Looks like you planned 2 tests but
> LT> only ran 1.
> LT> t/pmc/signal............ok
>
> LT> It seems, that due to the fork, the test system is getting an empty
> LT> test result too.
>
> Test::* can't handle output from forked children (it traps redirect
> STDOUT in the current process so it has no access to STDOUT of a
> child). this is a known problem. there are several ways around it. one,

I had similar problem before with Test::More tests.

Try silencing the child with something like:
{
no warnings 'redefine';
*Test::Builder::_ending = sub {};
}
before exit(0).

This assumes that Parrot uses Test::Builder, which seems to be the
case from a quick grep :)

Thanks,
Boris

[Leopold Toetsch]

Uri Guttman wrote:

>>>>>>"LT" == Leopold Toetsch <l...@toetsch.at> writes:
>>>>>>
>
> LT> The attached t/pmc/signal.t should send a SIGINT to a sleeping or
> LT> looping PASM test. This basically works, but the test output looks a
>

> Test::* can't handle output from forked children (it traps redirect
> STDOUT in the current process so it has no access to STDOUT of a
> child).

I've now changed the code and use an SIGALRM handler to send a SIGINT to
parrot. Works fine.
Thanks for your comments,

> uri

leo

[Michael G Schwern]

On Tue, Jan 27, 2004 at 12:49:25PM -0500, Uri Guttman wrote:

> Test::* can't handle output from forked children

Yes, the problem is the child process can't inform the parent of how many
tests it ran. The simplest way around this problem is to have the
parent account for any tests run in the child by incrementing the test
counter manually.

use Test::More tests => 4;
my $builder = Test::More->builder;

pass 'some test in the parent';
if( fork ) {
# account for the one test run in the child.
$builder->current_test($builder->current_test + 1);
pass 'another test in the parent';
}
else {
pass 'a test in the child';
exit;
}

pass 'one last test in the parent';

It can also sometimes make things less complicated if you shut off test
numbers ($builder->use_numbers(0)).

--
Michael G Schwern sch...@pobox.com http://www.pobox.com/~schwern/
If it's stupid, but it works, it isn't stupid.