develooper Front page | perl.perl5.porters | Postings from June 2019

[perl #134172] commit 027471cf breaks t/op/sprintf2.t on FreeBSD-11

Thread Previous | Thread Next
Hugo van der Sanden via RT
June 11, 2019 13:30
[perl #134172] commit 027471cf breaks t/op/sprintf2.t on FreeBSD-11
Message ID:
On Tue, 11 Jun 2019 05:59:02 -0700, jkeenan wrote:
> Smoke results are looking good.  I intend to merge this branch into
> blead within 24 hours unless we get bad results or someone objects.
> TonyC, does this look okay to you?
> Hugo, would you like to suggest a better commit message?

I don't think this should be merged at is, it was intended only as a proof of concept.

In particular, I strongly dislike the additional 5 lines (in a NOTREACHED area) simply to satisfy the macro's expectations of balance: if we keep the current general structure, the solution here will also need to be wrapped around any other part of the code that can bypass the unlock, and I anticipate there will be quite a few such areas.

I've looked some more today, and I think a larger change would be merited, but I'd want some input from DaveM and Karl.

I feel the problems here are essentially a clash between the work from bc37e90eb: "Perl_sv_vcatpvfn_flags: set locale at most once" and from e9bc6d6b: "Add thread-safe locale handling". Because of the mutex requirements of the latter, attempting to retain the former will need us to identify every possible route out of sv_vcatpvfn - not only the explicit croaks, but also eg any attempt to read an SV that might be tied or overloaded.

I don't think that's a practical thing to do; as such, I'm not convinced there's a practical route to getting correct mutex-protected locale changes on the platforms that need it while retaining the "do this only once" performance benefits.

What I'm not sure of is whether _some_ of the "only once" benefits can be retained, eg to discover if switching is necessary - I suspect that subsidiary code (such as tied and overloaded arguments, again) might make that unsafe even in an unthreaded application.

I guess another possibility would be to put an unlock request on a save stack, but that feels like it's going even further in the wrong direction - you want to be shortening the time you hold a mutex rather than lengthening it.


via perlbug:  queue: perl5 status: open

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About