A far simpler solution (that I've posted before recently) is to
output test "numbers" like
.1.1
.1.2
.1.3
.2.1
.2.2
.1.4
etc where the first number signifies the thread/process and the second
is just an increasing sequence within that thread. The . is there at
the start so that Test::Harness doesn't get upset.
Interprocess comms using Storable seems like overkill and sounds like
the sort of thing that would have "fun" bugs,
F
On 3/28/06, Tassilo von Parseval <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I was told that Test::More patches should now go to this list so here we
> go.
>
> The attached patch serves as a draft for enabling test-scripts that fork
> without the test-counter getting confused. It does so by using a
> Storable imaged shared between the processes. The patch however does
> need some modification because there's a race condition in there. It
> uses lock_nstore and lock_retrieve to store the current test-metrics
> thusly:
>
> +sub _inc_testcount {
> + my $self = shift;
> +
> + if( not $self->{Forked} ) {
> + lock $self->{Curr_Test};
> + $self->{Curr_Test}++;
> + return;
> + }
> +
> + # we are running in forked mode, therefore
> + # get data from disk, modify and write back
> +
> + my $stats = lock_retrieve( $self->{Forked} );
> + $self->{Curr_Test} = ++$stats->{Curr_Test};
> + $self->{Test_Results} = $stats->{Test_Results};
> + lock_nstore( $stats => $self->{Forked} );
> +}
>
> This is not quite correct. Instead, the member $self->{Forked} should be
> turned into a rw-filehandle to the storable image (it is the path to the
> image right now) and _inc_testcount() would become something like that:
>
> ...
> # we are running in forked mode, therefore
> # get data from disk, modify and write back
>
> # enter criticial region:
>
> lock $self->{Forked}, LOCK_EX;
> my $stats = fd_retrieve($self->{Forked});
> $self->{Curr_Test} = ++$stats->{Curr_Test};
> $self->{Test_Results} = $stats->{Test_Results};
> nstore_fd( $stats => $self->{Forked} );
> lock $self->{Forked}, LOCK_UN;
>
> # criticial region left
>
> A similar approach is needed for _store() and essentially for everything
> that now uses lock_nstore/lock_retrieve.
>
> Also, a test-case for this feature is tricky to conceive as
> Test::Builder::Tester can't be used here. I supplied one but it's quite
> messy.
>
> I am right now in the middle of relocating to NY so I don't have the
> time to do these modifications myself so maybe someone with more time on
> his hands could look after that. It's not so tricky and mostly involves
> some local changes to the enclosed patch.
>
> Cheers,
> Tassilo
> --
> use bigint;
> $n=71423350343770280161397026330337371139054411854220053437565440;
> $m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
>
>
>
