New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why does this module need multiplicity? #2
Comments
|
What exactly makes you think that Inline::Perl6 needs multiplicity? |
|
Because when I build it works, but running any of the tests I get: The build parameters for the perl are: |
|
Turns out this was a regression caused by a change in Inline::Perl5 which is now fixed in niner/Inline-Perl5@de59782 Please upgrade your Inline::Perl5 to 0.9. Then you can use your normal perl installation. |
Is multiplicity a true hard requirement for this module? I've written XS modules for perl 5 that do:
Thus I don't see why it wouldn't work to:
Or:
Is it possible that use-case A..C doesn't require multiplicity? That would already be quite nice because you could use this to bootstrap Perl 6 code for things that have an existing P5 API. Like mod_perl, or uWSGI's perl module, irssi plugins etc. You wouldn't be able to call any p5 code from Inline::Perl6, but that would be OK.
Or maybe A..F is possible. I can't see why, ignoring perl6 I've written C XS modules for Perl 5 that do exactly these sort of calls. Since there's no concurrency it works just fine.
Or is the multiplicity just because this is going to clone another interpreter for any hyperthreading ops? Maybe those could be disabled using some facility or forced to be serialized?
Aside from the "I need to recompile my perl" inconvenience having it need to spawn multiple perl interpreters could have a very bad (and silent?) impact on load times & memory use.
The text was updated successfully, but these errors were encountered: