Since my recent participation at the QA Hackathon I have become aware that rather more people than I expected do not know the specifics of this situation. Fewer than I expected have heard of it at all, even, although there appears to be some general awareness at the “something happened with that” level at least.

However, the situation is being used to characterise Marc Lehmann whenever his name comes up (and it comes up rather more often than I would expect or consider necessary).

To give a clear picture of the facts and to avoid repeating that exercise every time I have a related conversation, here is an outline of where we are and how we got here.

(Thanks to Andreas König, Graham Knop, and Peter Rabbitson for proofreading drafts of this article and verifying the stated facts.)

Objectively

Here is a timeline of relevant events:

Interlude

The still-unreverted patch was also reported (in perl #123687) to affect mod_perl 2, where it was fixed as documented in RT #101962, resulting in patch 82827132efd3. The solution was to increase the complexity of the hooking code, so that it can inject the same workaround as before but into a different point of the internals where it has a more limited scope. Contrast the amount of volunteer effort with the 4kb per process savings.

In all this, mod_perl 1 went entirely unaccounted for. It is unknown whether any users have tried to use it with perl 5.22, which can be expected not to work. Note also that c910fead7893 removes a comment which mentions that some SWIG bindings require the ability to hook those internals which just got removed.

Subjectively

People have been speaking of Marc Lehmann “refusing” to support 5.22 in Coro. It has been suggested that he could try to find a workaround.

But for one, if it is fixable, it is highly non-obvious how. The way mod_perl 2 was fixed does not appear applicable to Coro due to difference in the specifics of the two situations. This is implicitly acknowledged by Corion’s comment in perl #125439:

I think Perl should take the code from Coro to make $SIG{__WARN__} always write+read PL_warnhook

… and further evidenced by the fact that the unofficial release of Coro does not have a workaround despite the expertise of Reini Urban.

And for another, even if a workaround were possible, consider that Coro was working around a bug to begin with. That workaround got broken. It is not clear that a different workaround would be future-proof, outside of p5p blessing one as such. Is it on Coro’s author to keep working around broken workarounds for the same bug whenever p5p breaks another one? Or is it on p5p to either fix the underlying bug or else avoid breaking its workarounds?

To be fair, the monkeypatching performed by Coro and mod_perl hooking into that table is very global: it affects every perl interpreter within a process (of which there can be several when perl is embedded in another program). Locking down this hook point is a sensible architectural decision in the abstract. This is rumoured to have been the reason the patch never got reverted. Indeed, for most use cases, it is already possible to hook into other points with more limited scope. This is how mod_perl was saved. But it’s not clear that every existing use case already has cleaner alternatives, and even the ones available are not currently well understood – not even by the developers who locked down the hook point. Consequently there was no attempt to help downstream developers who had previously employed monkeypatches: no attempt was made to survey existing use cases, no documentation was added about clean and future-proof alternatives to existing monkeypatches, no helper functions to make those approaches more approachable… no aid of any kind. Such efforts would have been part of a carefully executed plan to promote cleaner coöperation among low-level extensions. Instead the commit message demonstrates the motivation for the patch prior to ex post facto justifications of its benefit.

Note this alternative sequence in which events could have played out:

When the 4kb-saving patch is found to break Coro and mod_perl, it gets reverted for the time being

A report about the underlying imperfect hook synchronisation bug is filed and a fix is written

A new major version of perl with the fix is released

The author of Coro is approached to say “your workaround has been made unnecessary in perl 5.$recently and later”

When the decision is made that this patch shall be re-applied, an effort is made to prepare the ecosystem (the surveying and documentation as mentioned above), during which the author of Coro is approached to say “the workaround should now be conditionalised because it will break in 5.$soon”

Nothing in that sequence is infeasible. It would have delayed the 4k-saving patch for a few releases, and in exchange it would have prevented any and all suffering inflicted on at least the maintainers and users of software built on Coro.

I close with a recent quote from the pumpking of Perl 5:

perlpolicy […] demands that we keep backward compatibility as much as possible. This is a huge deal for Perl 5, for a lot of reasons. For one, it means that we don't knowingly break things unless we believe there's a good reason – and we’ve been trying to tighten up “good reason” a bit over time. This means that it's almost always safe to upgrade your perl without unpleasant surprises. The “incompatible changes” section of the changelog file should be short and fairly exhaustive.

Emphasis mine.