On Sun Jan 03 14:59:46 2016, SREZIC wrote:
Show quoted text> Given that there are more problems with XSConfig (the UNINST issue,
> other modules fiddling with %Config::Config) --- have you considered
> to simply install XSConfig.pm as XSConfig.pm? It could set
> $INC{"Config.pm"}, so that a subsequent "use Config" is be a no-op.
> Users interested in the performance benefits could either manually
> symlink/copy XSConfig.pm to Config.pm (if they know that there are not
> affected by possible problems), or better, write "use XSConfig" in the
> principal script/webserver/.... Or use something like PERL5OPT=-
> MXSConfig.
I thought about it, XSConfig is useless if it doesn't replace PP Config.pm 100% of the time. In Cperl, XS Config is the only Config.pm, so this bug ticket is indirectly filed against Cperl. Fixing a bug on CPAN in XS Config will fix the same bug in Cperl core. Changing Config.pm to XSConfig.pm on CPAN won't fix the same bug in Cperl.
Rewriting your own code to say "use XSConfig;" is too much work. There is also the issue of, if PP Config was already loaded in the process through some way (perl debugger, env vars, whatever), then some module does "use XSConfig;", then what? clean out the Config:: package globs at runtime to avoid redefined errors? CPU+memory churn. Plus I'm not sure I can free the big long PP Config DB string with all the settings.
I think there are 2 ways to solve the %Config manipulating modules problem.
1st solution a module makes a copy of %Config to another hash, then does untie(%Config), then copies the other hash back to %Config. %Config is now a regular RW hash (memory usage regardless). What class (XS/PP) used to implement %Config is irrelevant.
2nd solution, XSConfig offers a Config::toPP() or Config::downgradetoPP() sub (a better sub name anymore?). This is in forks.pm
BEGIN {
require Config;
my $h = tied %Config::Config;
$h->{useithreads} = 1;
}
and would become
BEGIN {
require Config;
Config::toPP() if defined &Config::toPP;
my $h = tied %Config::Config;
$h->{useithreads} = 1;
}
XSConfig during its self testing loads PP Config into a process that previously loaded XS Config process, and %Config becomes the PP implementation at runtime so runtime downgrading is possible, it just needs a documented API to do it.
https://metacpan.org/source/BULKDD/XSConfig-6.06/t/XSConfig.t#L31
So if forks.pm calls Config::toPP() before called tied, it will be the PP implementation. I think this is a reasonable compromise. Since XS Config is the *ONLY* Config in cperl, looking down the road, it is not impossible that P5P perl one day would have XS Config in core, so either inflating and untie %Config solution or Config::toPP() must be implemented today. Nobody can deny forks.pm is using undefined behavior in manipulating %Config so a fix that requires patching forks.pm is reasonable.
3rd solution, a Config::setkey sub as a "YES I really want to write to RO data" sub, but P5P/PP Config doesn't have such an API and wont until 5.26 at the minimum, which doesn't solve the problem of %Config manipulating code needing to be back compat to PP Config.pm from as old as 5.8, so solution 3 wont work.
There doesnt seem to be more than a couple modules that manipulate %Config
http://grep.cpan.me/?q=tied%28\%28|\s*%29%25Config
The UINST bug is partially fixed, it can't damage without human intervention smoker perl installations the way it was before, it just fails to automatically install now if it detects an unexpected UNINST=1.
