Eric Wilhelm wrote:
> # from Michael G Schwern
> # on Thursday 29 November 2007 19:00:
>
>> Otherwise, what's important to people?
>
> Could it be made fork-safe?
>
> http://search.cpan.org/src/TJENNESS/File-Temp-0.19/t/fork.t
>
> Possibly that involves blocking, or IPC with delayed output, or a
> plan-per-fork thing.
The trick is, how do you do it?
IPC is right out, unportable. I'm pretty sure there's no way to coordinate
the test counter between the two processes. There are TAP proposals to
eliminate the need for coordination but I don't want to get into that right now.
The usual way to do this is to turn off test numbers, fork and then turn them
back on when the fork is done while incrementing the test counter by the
number of tests the fork ran. That requires a bunch of Test::Builder method
level muckery and is non-obvious.
An easier Test::More level interface would be nice, but what would that
interface be? It needs an "I'm about to fork for this many tests" function
and a "I'm done forking" function. It would be easier if Test::More did the
forking for you, but that's a restriction I don't want to impose.
Or maybe we just write Test::Fork like so:
use Test::Fork;
fork_ok(sub {
is 23, 42; # this is the code in the fork
});
and it does all the necessary jiggery pokery. Knowing when the fork is
complete to turn numbers back on is troublesome. I guess some sort of signal
handler will deal with that?
PS I note there is Test::MultiFork but it seems to go well beyond what we're
talking about.
--
...they shared one last kiss that left a bitter yet sweet taste in her
mouth--kind of like throwing up after eating a junior mint.
-- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest
by Tami Farmer
