As I said, I do not really know the details. This is not my main work, but an application for which I only work occasionally. It was previously working on 5.8, if I remember correctly (or perhaps 5.10, but I think it was 5.8), and they decided to upgrade because they wanted to use threads in a new framework developped internaly, and, apparently, it does make a difference. I do not know the details personally, but I would tend to trust the person who proposed that upgrade decision, because I know it is someone who usually knows fairly well what he is doing.
But the point is that the improvement was compared to Perl 5.8, not a more recent version.
| [reply] |
| [reply] |
I don't think these could be classified as "much better" improvements to Perl's threads, but there are some bug fixes listed in perl5160delta that target threads. Perl 5.18.0 has some additional fixes, but they appear less significant than those in 5.16.0. However, at least one of the bug fixes under 5.18.0 targets threads on Win32, which I think is one of platforms you commonly use.
If your code isn't tickling any of those bugs, fixes to thread support alone probably wouldn't be sufficient motivation to upgrade. For me, some of the Unicode support improvements found in 5.16.x were motivation enough to migrate to 5.16.
The list of modules that are broken in ways incompatible with Perl 5.18 is still significant enough, in my opinion, to wait awhile for module authors to have time to respond to the wake up call and fix their code that relies on hash order. I installed it in a perlbrew environment to see which, if any, of the modules that I frequently employ were going to be problematic, and discovered at least one that needs to have a broken test fixed.
| [reply] |