Ability to spawn Parrot processes from PIR in tests

[whiteknight]

the tests in t/op/spawnw.t all rely pretty heavily on the existence of Perl5. Each tests spawns an instance of perl and tests various return values from it. I suggest we should try to replace these with tests to spawn new instances of Parrot (or something else, possibly system dependent).

[jkeenan]

Replying to whiteknight:

the tests in t/op/spawnw.t all rely pretty heavily on the existence of Perl5.

Well, seeing that the test itself is written in Perl5, that's a quite reasonable assumption :-)

I suggest we should try to replace these with tests to spawn new instances of Parrot (or something else, possibly system dependent).

Is Parrot itself fast enough yet that it would be reasonable to use in these tests?

kid51

[dukeleto]

Yes, we *really* need an easy way to create a new parrot process from within PIR, so that we can write certain tests that require this. I am *on* it.

We should not go the "system dependent" route.

[cotto]

r42521 will likely be helpful in this task. I went the route of modifying FileHandle to keep track of the exit status of any children run in a pipe. I don't know if this is preferable to having spawnw keep track of the exit code. I just picked the one that seemed easier at the time. Either way, the code is in place and any stupid API decisions on my part can be modified since there hasn't been a "supported" release containing the change.

[bacek]

Hello.

What we need is actually exit opcode to test spanw. Then we can rewrite this tests in pir/nqp/whatever. Perl is used just as convinient wrapper for "exit".

-- Bacek

[cotto]

The tests in t/profiling/profiling.t depend on running PIR and nqp-rx code in a child process, verifying the output and the exit code. Is there any reason to keep this ticket open?

[cotto]

whiteknight seems to be happy, so I'm closing this ticket.