Front page | perl.perl5.porters |
Postings from May 2016
---------------------------------------- > Date: Tue, 3 May 2016 19:40:22 +0100 > From: nick@ccl4.org > To: davem@iabyn.com > CC: perl.p5p@rjbs.manxome.org; perl5-porters@perl.org; xsawyerx@gmail.com > Subject: Re: revert MG consting (Coro breakage) for 5.24? > > On Tue, May 03, 2016 at 04:56:31PM +0100, Dave Mitchell wrote: >> I propose that we revert this commit for 5.24 (we need another RC anyway >> for the SvGROW) issue. > > What does this gain? > > Coro still won't compile against 5.24.x without other changes (due to your > context stack reworking), and still won't compile against 5.22.x (because this > wouldn't be backported). > >> This should have relatively minimal effect (apart from 4K extra memory >> usage per process), since all it would be doing is removing a constraint >> on XS code (the vtable array can now be modified by XS code again). > > So as best I can tell, all this achieves is a 4K increase in memory usage > per process. It doesn't fix Coro. What's the upside? > > Nicholas Clark Compat of coro with already shipped 5.22 is done by changing VM perms on the memory page holding the vtable using OS specific APIs. Since Coro's author wont ask for P5P assistance, runtime binary patching of perl interp from an XS module is reasonable. It the same thing you do with impossible to work with FOSS devs who take patch submissions to be an ego hit or closed source software . MS Detours, EasyHook, or Deviare are what you/I use when you/I decide the other side is unworkable, which schmorp did with p5p, but he dropped support for p5p perl too. Hooking classes, or hooking vtables, rewriting machine code in real time, "monkeypatching", is almost never the right solution, unless its a social failure.