perl.perl5.porters https://www.nntp.perl.org/group/perl.perl5.porters/ ... Copyright 1998-2021 perl.org Sat, 10 Apr 2021 21:25:26 +0000 ask@perl.org a perl SMP safari by B. Estrade I. Introduction<br/><br/>TLDR; I am dropping the &quot;thread&quot; thing. I don&#39;t think this is helpful. <br/>It also doesn&#39;t affect the following, which has always been the goal - <br/>SMP/multi-core semantics for easier and more fun multi-core programming.<br/><br/>One thing about perl/Perl that I absolutely love is that there is a set <br/>of &quot;secret&quot; or &quot;discovered&quot; idioms and capabilities. For whatever <br/>reason, due to leveraging &quot;it&#39;s a feature not a bug&quot;, the side effect of <br/>doing other things on purpose, or just straight wizardry we have things <br/>like Perl&#39;s set of secret operators [0]. Seems like the Schwarzian <br/>Transform [1] falls into this camp.<br/><br/>Given the introduction, I am on a similar search for the tiny cracks and <br/>opportunities in any part of the perl/Perl stack that might be <br/>sufficient (or necessary) hidden opportunities for &quot;interesting&quot;.<br/><br/>II. A Hopeful Example of What&#39;s Possible Today: Coordination of Child <br/>Processes, using fork and the Atomicity of open(2)<br/><br/>One example, &quot;atomicity&quot;. Child processes (and really of any origin) can <br/>exploit kernel level support for necessary atomics in the &#39;open&#39; syscall <br/>via Perl&#39;s &quot;sysopen&quot; directly; this is also exposed by using &quot;symlink&quot; <br/>(See File::Symlink::Atomic). Therefore I can conclude that Perl has core <br/>support for a very basic form of atomics.<br/><br/>What&#39;s the use case for this that is useful now? The most basic form of <br/>this is a developer wishes to do some work using a number of fork&#39;d <br/>processes. However, during the course of the work, there is a part that <br/>must be coordinated among non-communicating sequential processes (and <br/>this term, I believe is super helpful given our situation). Using the <br/>atomic capabilities of the operating system, well outside the scope of <br/>the perl processes, we can provide a wall that all processes must admit.<br/><br/>E.g.,<br/><br/>sub go_nucular {<br/> # do something that leverages sysopen or symlink&#39;s kernel<br/> # level atomicity<br/>}<br/><br/>my $cid;<br/>my $complicated_ds = _get_scarey_HoHoAoAoH(); # you get the idea<br/>for (1..10) {<br/> $cpid = fork;<br/> if (not $cpid) {<br/> # kid does stuff<br/> ..<br/> # kid tries to do &quot;atomic thing&quot; until successful<br/> while (not my $w00t = go_nucular($complicated_ds) { cry() };<br/><br/> # kid is done, mom calls for dinner; time to go home and eat tendies<br/> exit;<br/> }<br/>}<br/># assume some form of wait or waitpid is here for the parent...<br/><br/>Notes about the above example:<br/><br/>1. is this a &quot;lock&quot; kind of but not really; it&#39;s optimistic; just like <br/>the kid who keeps trying to run through a wall; there is no explicit <br/>knowledge of the barrier to the child<br/><br/>2. not even the parent perl process is aware of this kernel level <br/>protection; if parent perl doesn&#39;t care in this case; there sure are <br/>other examples where we can use kernel level guarantees for other <br/>interesting things that the parent perl process doesn&#39;t need to know about<br/><br/>3. in reading up on fork just to make sure I didn&#39;t make a totally bone <br/>headed assertion, I read this:<br/><br/>&quot;File descriptors (and sometimes locks on those descriptors) are shared, <br/>while everything else is copied.&quot; [2]<br/><br/>I gotta say, this is excited. It used the word &quot;share&quot;. I have not <br/>tried, but seems accurate to say a &quot;shared&quot; file handle among all <br/>processes is right up open(2)&#39;s ally. It might (_might_) even expose <br/>some potential to be exploited in more interesting ways. I don&#39;t know <br/>anything about a file handle descriptor. But something inside of the <br/>system support for Perl&#39;s &#39;fork&#39; is a mechanism by which newly minted <br/>child processes given one.<br/><br/>II. The Hunt<br/><br/>Motivated by [0], [1], and the example above; the challenge can be <br/>stated simply:<br/><br/>What hidden opportunities are there in perl/Perl RIGHT NOW that can be <br/>used TODAY as a basis for exploiting the OS for doing interesting things <br/>like SMP or introducing perlish atomic semantics? In addition taking <br/>full advantage of how well perl/Perl understands the unix system model <br/>and underlying operating system, what language features ideas can this <br/>generate for serious consideration. Maybe if we can&#39;t have &#39;real SMP&#39;, <br/>perhaps we can explore semantics that make it more nature to use fork, <br/>on a high level, in the same way.<br/><br/>Here is a list of &quot;challenges&quot; I think would be useful, either as actual <br/>questions to answer - or as prompts for &quot;thought exercises&quot; or p5 fanfic:<br/><br/>1. what additional syscalls can be exploited (legally abused) for <br/>atomicity or more interesting things?<br/><br/>2. how can sysopen be used to implement a construct for us by child <br/>processes in a fork context, such as one that presents a forked <br/>environment in which the parent also participates (keywords/names are <br/>just for clarity, I care only about semantics):<br/><br/> my $MAX_PROCS = 8;<br/> do_all($MAX_PROCS) {<br/> # wait barrier for all children based on sysopen<br/> critical {<br/> # do stuff with the guarantee that no other in the family of<br/> # processes are executing this code<br/> }<br/> while_waiting(maxattempts =&gt; 10, bail_msg =&gt; q{I&#39;m out. Something <br/>wrong.}) {<br/><br/> }<br/> }<br/><br/>I am not going to do it, but I am 100% sure that can be implemented <br/>right now in babby perl using just fork, sysopen, alarm, and die.<br/><br/>It also looks suspiciously like the semantics of try/catch (hmmm). What <br/>is the win? Semantics that allow Perl to &quot;get out of the way&quot; (finally) <br/>when doing things in a multi-process way.<br/><br/>3. are there opportunities to provide child processes &quot;shared&quot; things, <br/>NOW? I go back to the note about &#39;fork&#39; above:<br/><br/> File descriptors (and sometimes locks on those descriptors) are<br/> shared, while everything else is copied. [2]<br/><br/>While the following can&#39;t be done in babby perl, I think it can be done; <br/>albeit there is danger here. But babies should not be doing this:<br/><br/> # parent perl process<br/> my %some_hash_of_cool_stuff = ( a =&gt; 3, s =&gt; &#39;yes&#39;, l =&gt; &#39;LA&#39; );<br/> my $hash_ref_of_uncool_stuff = { J =&gt; 42, m =&gt; 12, j =&gt; sin(180) };<br/> my $what_I_had_for_lunch =&gt; q{pineapple pizza};<br/> my @mbox<br/> open my $shared_fh, q{&gt;}, q{/tmp/a-file} or die;<br/> my $MAX_PROCS = 8;<br/><br/> do_all($MAX_PROCS, shared =&gt; [\%some_hash_of_cool_stuff, <br/>$hash_ref_of_uncool_stuff, $what_I_had_for_lunch]) {<br/> my ($cool_ref, $uncool_ref, $lunch) = shared_refs; # lunch is a <br/>scalar ref<br/><br/> my $fid = ${^FORK_ID}; # we are forking, right? parent gets id 0<br/><br/> # S A F E - reads on &quot;shared&quot; things<br/> local $cool = $%some_hash_of_cool_stuff;<br/><br/> # U N S A F E (and warns akin to &quot;Deep recursion scariness&quot;)<br/> if ($fi == $MAX_PROCS - 1) {<br/> # the last born are always the most entitled, so:<br/> $$lunch = q{YOU had pineapple pizza, you gave me cold oatmeal. <br/>You&#39;re not even my read dad!!};<br/> }<br/> }<br/><br/>What are we looking at above?<br/><br/>a. a &quot;do_all&quot; that creates a set of forked processes, including parent <br/>that do the same stuff<br/>b. in addition to $$, there is a &quot;${^FORK_ID}&quot; that is in the range, <br/>0..$MAX_PROCS-1<br/>c. list of references to share to the children on fork; I figure if <br/>&quot;open&quot; can share a file descriptor, it can share a pointer to perl data <br/>structures<br/><br/>I&#39;ve tried my hardest to do this what I considered to be the salient <br/>restrictions. Note, I don&#39;t mention &quot;SMP&quot; but I have tried to use what I <br/>think it&#39;d look like semantically (today&#39;s forks are tomorrows threads). <br/>In addition to that, I&#39;ve snuck in the potential for SMP communication <br/>over the set of shared points.<br/><br/>OMG, does this expose some &quot;safety&quot; issues? Yes, and I love it.<br/><br/>4. Is there a hidden opportunity with &quot;open&quot;? In particular, if all <br/>children (NOW) get to share a file descriptor, does this apply to ... oh <br/>yes it does. Sorry to stop mid-thought, but low and behold in [2], under <br/>the section &quot;Opening a filehandle into a command&quot;, are these very <br/>interesting words:<br/><br/> If you open a pipe on the command - (that is, specify either |- or -|<br/> with the one- or two-argument forms of open), an implicit fork is<br/> done, so open returns twice: in the parent process it returns the pid<br/> of the child process, and in the child process it returns (a defined)<br/> 0. Use defined($pid) or // to determine whether the open was<br/> successful.<br/><br/>And this leads to my fifth and final question in today&#39;s installment;<br/><br/>5. How can perl expose fundamental unix IPC, in the context of &quot;fork&quot; <br/>using perlish semantics (get outta the way, DWIM, etc)? There are lots <br/>of exciting things I can think of with this one. And that&#39;s even before <br/>I throw out the words &quot;object serialization, wireline protocol, or <br/>redis&quot;. But ultimate those things are not &quot;shared&quot; memory. They are cool <br/>and we should provide semantics for this, but that&#39;s more in the realm <br/>of data brokers and comm channels. But it&#39;s interesting and exciting, <br/>and totally doable in perlish ways.<br/><br/>Above I have expressed some ideas and examples. Some are possible NOW. <br/>Some not far off.<br/><br/>The essential elements of what I trying to get can be summed up as this:<br/><br/>* perl/Perl has riches yet to be discovered; we likely have all we need <br/>now; if not the little remaining is not going to stand in the way<br/>* still more, things that can be used to extend the language <br/>semantically and that are useful in practice<br/>* let&#39;s go out and find them, put them together in perlish ways, and get <br/>excited doing it<br/>* it really is about exposing the unix os in perlish ways; ultimately <br/>this is where my borderline obsession with all of this comes from<br/><br/>Finally, given the above and the fun I&#39;ve had in going on this Perl <br/>safari; I will concede to not using the term &quot;threads&quot;. It would be <br/>sufficient to marry perl semantics using fork and the rich and diverse <br/>toolkit already in perl and at arms reach in the OS userland, kernel. If <br/>successful, it won&#39;t matter what backs the lines of execution; they <br/>could be threads; more practically they are forks. I&#39;m ok with that part <br/>of it (for now).<br/><br/>Refs:<br/><br/>0. https://metacpan.org/pod/distribution/perlsecret/lib/perlsecret.pod<br/>1. https://www.perl.com/article/the-history-of-the-schwartzian-transform/<br/>2. https://perldoc.perl.org/functions/fork<br/>3. https://perldoc.perl.org/functions/open<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259784.html Sat, 10 Apr 2021 20:59:33 +0000 Re: The Purpose of P5P by Philip R Brenan Another comprehensive report from NeilB! <br/> <br/>I say that we can have wildly new capabilities that completely break the <br/>existing language if they are safely controlled by a *use* and *no* <br/>pragama. As in: *no sigils; use autoderef; * Developers care deeply about <br/>the language they use. We will not attract new developers with the existing <br/>antiquated syntax. Nor should we be allow some small group to dictate what <br/>the language is when the *use* and *no* pragmata can safely allow new <br/>lexers, parsers and code generators to be slotted seamlessly into position <br/>without disrupting existing users*. *We can have the best of both worlds: <br/>stability and simultaneously the &quot;more than one way to do it ness&quot; that <br/>brought people to Perl in the first place. Software represents the <br/>organization that produces it: we seem to be incapable as an organization <br/>of exploiting the good work already done with pragmata as effectively as we <br/>should because we get endlessly bogged down in use *v7*. Are we really <br/>saying that our only ambition is to fade securely and reliably away into <br/>the very last syllable of recorded time? <br/> <br/>On Sat, Apr 10, 2021 at 9:14 PM Neil Bowers &lt;neilb@neilb.org&gt; wrote: <br/> <br/>&gt; The purpose of P5P is &quot;the development and maintenance of Perl&quot; &acirc;&#128;&#148; easy, <br/>&gt; right? The &quot;perlpolicy&quot; doc expands on this in some areas, but in PSC <br/>&gt; discussions we still found ourselves revisiting this, and I tried various <br/>&gt; times to write up our thoughts. <br/>&gt; <br/>&gt; Various points related to this have come up in discussions on P5P, so I <br/>&gt; think it might be helpful to see how much of this we agree on. Think of <br/>&gt; this as P5P&#39;s mission statement, or manifesto. <br/>&gt; <br/>&gt; We think our priorities are, in decreasing order: <br/>&gt; <br/>&gt; 1. Deal with security issues promptly (Security). <br/>&gt; 2. Keep perl code running (Reliability). <br/>&gt; 3. Improve the language for developers who are maintaining existing code <br/>&gt; or writing new code (Effectiveness). <br/>&gt; 4. Provide reasons for people to return to Perl, or to start writing <br/>&gt; Perl (Growth). <br/>&gt; <br/>&gt; One of the points of contention is the priority of Reliability vs <br/>&gt; Effectiveness: there&#39;s a lot of old code out there that no-one cares about <br/>&gt; (any more) &acirc;&#128;&#147; do we really think keeping that code running is more important <br/>&gt; than extending the language to support today&#39;s active developers? Let&#39;s <br/>&gt; look at the priorities in turn, and then revisit this question. <br/>&gt; <br/>&gt; <br/>&gt; *Security* <br/>&gt; <br/>&gt; If security bugs are reported or discovered, then they are given <br/>&gt; appropriate priority, and they will often outweigh other considerations. <br/>&gt; When addressing security issues, we hope that the fix won&#39;t impact the <br/>&gt; other considerations. Sometimes that&#39;s not possible though, and security <br/>&gt; wins out. For example, &quot;no . in @INC&quot;. <br/>&gt; <br/>&gt; This is not only &quot;fix security bugs&quot;, but also &quot;try and prevent security <br/>&gt; bugs in Perl&quot;. <br/>&gt; <br/>&gt; <br/>&gt; *Reliability* <br/>&gt; <br/>&gt; Once someone has written Perl code and it has been &quot;put into production&quot;, <br/>&gt; we should do our best to ensure that it continues to work when they upgrade <br/>&gt; to a new version of Perl. Perl has a reputation for backward <br/>&gt; compatibility, earned over decades. That reputation is valuable, and we <br/>&gt; should only spend that capital in return for something sufficiently <br/>&gt; valuable to warrant it. <br/>&gt; <br/>&gt; - Aim for backwards compatibility when introducing new features. <br/>&gt; - Fix bugs, while remembering that sometimes bugs become relied upon, <br/>&gt; and fixing those ones can break code. <br/>&gt; - Be mindful of the breakage of CPAN code, which is our best proxy for <br/>&gt; how proprietary code may break. <br/>&gt; <br/>&gt; This doesn&#39;t mean that we must be 100% backwards compatible and never <br/>&gt; break any CPAN modules, but that we should only deviate from that when <br/>&gt; we&#39;ve carefully considered the impact. If a change would break three <br/>&gt; twenty-year old modules on CPAN that no-one seems to use, that&#39;s a <br/>&gt; different proposition from breaking a module that&#39;s far up the CPAN River. <br/>&gt; <br/>&gt; Furthermore, if we do decide that it&#39;s ok to break something, we should <br/>&gt; try to reduce the inconvenience it causes by providing advance notice, <br/>&gt; clear documentation, and, when possible, tooling or other assistance. <br/>&gt; <br/>&gt; It&#39;s easy to think that perl is just about what you do in perl, but over <br/>&gt; the years perl has been used, and is still being used for a broad range of <br/>&gt; things. I think it would help us to have a shared picture of those, but <br/>&gt; that&#39;s for another day. <br/>&gt; <br/>&gt; <br/>&gt; *Effectiveness* <br/>&gt; <br/>&gt; This is about continuously evolving and improving Perl, to make the lives <br/>&gt; of active Perl developers better: increase productivity, prevent common <br/>&gt; bugs, improve performance, etc. <br/>&gt; <br/>&gt; Some of this is about filling gaps in the features provided by Perl, which <br/>&gt; developers may be used to from other languages. <br/>&gt; <br/>&gt; This can also be small incremental improvements in the language, <br/>&gt; particularly where we have the evidence to support them, for example where <br/>&gt; people regularly make the same mistake, or there&#39;s an commonly used idiom. <br/>&gt; To borrow a phrase from Nicholas, if we think something should be in the <br/>&gt; FAQ, then we should also consider whether it&#39;s something the language <br/>&gt; should provide. <br/>&gt; <br/>&gt; This might also be by including additional modules in the core. There are <br/>&gt; differing thoughts here: some want to see more batteries included, but <br/>&gt; every additional core module is additional maintenance and release work. <br/>&gt; <br/>&gt; When adding new features or feature bundles, we also need to think about <br/>&gt; all the existing code out there and how we help it bridge the gap without <br/>&gt; requiring a stressful flag-day effort. <br/>&gt; <br/>&gt; <br/>&gt; *Growth* <br/>&gt; <br/>&gt; Many of the features that we&#39;d like to see in Perl are things that have <br/>&gt; been provided by plenty of other languages for years. We&#39;re playing <br/>&gt; catch-up. Many of these features aren&#39;t likely to attract significant <br/>&gt; numbers of new developers, but the aggregate effect of them will hopefully <br/>&gt; bring us up to par. <br/>&gt; <br/>&gt; Considering the leaky bucket model, some of the things we can do for <br/>&gt; growth are really about reducing leakage. <br/>&gt; <br/>&gt; That said, there are no doubt changes we could make to give Perl an edge <br/>&gt; over other languages, some of which have been called for in recent <br/>&gt; discussions. But we have to remember the resources we have available and <br/>&gt; that we&#39;re a volunteer organisation. <br/>&gt; <br/>&gt; What will really attract new Perl developers in greater numbers is CPAN <br/>&gt; distributions for emerging domains. Lots of people have learned Python <br/>&gt; because of the machine learning support. There&#39;s a chicken and egg problem <br/>&gt; here, but it&#39;s not one for P5P to try and solve. <br/>&gt; <br/>&gt; It&#39;s also tempting to bundle Effectiveness and Growth together, but I <br/>&gt; think it&#39;s worth separating them, as (a) I think the things that will <br/>&gt; attract significant numbers of developers aren&#39;t the language, and (b) some <br/>&gt; significant changes to the language possibly would attract new developers, <br/>&gt; but at the cost of existing developers, which in general isn&#39;t a trade-off <br/>&gt; I think we should make. <br/>&gt; <br/>&gt; <br/>&gt; *Final Thoughts* <br/>&gt; <br/>&gt; These aren&#39;t gates, but an order in which we should consider things. It <br/>&gt; doesn&#39;t mean that we can&#39;t consider changes that will break things, but <br/>&gt; that we have to make an informed decision, and that some considerations are <br/>&gt; more important than others. A sexy new feature that might attract hordes of <br/>&gt; new developers won&#39;t be acceptable if it makes Perl less secure, or <br/>&gt; inconveniences significant numbers of our existing users or current <br/>&gt; developers. <br/>&gt; <br/>&gt; None of this is surprising or new. It&#39;s an attempt to write down what I <br/>&gt; think most people feel. Some of these ideas are already built-in to how new <br/>&gt; capabilities are rolled out, with feature guards, for example, and the &quot;use <br/>&gt; vN&quot; version bundles. <br/>&gt; <br/>&gt; So, should reliability of old code come ahead of the e of current <br/>&gt; developers? There&#39;s surely some existing perl code in the wild that no one <br/>&gt; cares about any more (let&#39;s call it &quot;abandoned code&quot;), and if we broke it, <br/>&gt; its owners wouldn&#39;t care. But we&#39;ve no way of identifying all the abandoned <br/>&gt; code, so it&#39;s unrealistic that we could define changes that would only <br/>&gt; break abandoned code. And if we tried this, then people would naturally <br/>&gt; worry that at some point in the future we might sacrifice their code&#39;s <br/>&gt; reliability to the new feature gods, and we&#39;d lose perhaps the strongest <br/>&gt; pillar of Perl&#39;s reputation. <br/>&gt; <br/>&gt; In addition to the priorities outlined here, we think there are principles <br/>&gt; that we apply as well. For example, in designing new language features, we <br/>&gt; should ensure they are consistent with the existing language. <br/>&gt; <br/> <br/> <br/>-- <br/>Thanks, <br/> <br/>Phil &lt;https://metacpan.org/author/PRBRENAN&gt; <br/> <br/>Philip R Brenan &lt;https://metacpan.org/author/PRBRENAN&gt; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259783.html Sat, 10 Apr 2021 20:44:48 +0000 The Purpose of P5P by Neil Bowers The purpose of P5P is &quot;the development and maintenance of Perl&quot; &acirc;&#128;&#148; easy, right? The &quot;perlpolicy&quot; doc expands on this in some areas, but in PSC discussions we still found ourselves revisiting this, and I tried various times to write up our thoughts. <br/> <br/>Various points related to this have come up in discussions on P5P, so I think it might be helpful to see how much of this we agree on. Think of this as P5P&#39;s mission statement, or manifesto. <br/> <br/>We think our priorities are, in decreasing order: <br/> <br/>&Acirc;&nbsp;&Acirc;&nbsp;1. Deal with security issues promptly (Security). <br/>&Acirc;&nbsp;&Acirc;&nbsp;2. Keep perl code running (Reliability). <br/>&Acirc;&nbsp;&Acirc;&nbsp;3. Improve the language for developers who are maintaining existing code or writing new code (Effectiveness). <br/>&Acirc;&nbsp;&Acirc;&nbsp;4. Provide reasons for people to return to Perl, or to start writing Perl (Growth). <br/> <br/>One of the points of contention is the priority of Reliability vs Effectiveness: there&#39;s a lot of old code out there that no-one cares about (any more) &acirc;&#128;&#147; do we really think keeping that code running is more important than extending the language to support today&#39;s active developers? Let&#39;s look at the priorities in turn, and then revisit this question. <br/> <br/> <br/>Security <br/> <br/>If security bugs are reported or discovered, then they are given appropriate priority, and they will often outweigh other considerations. When addressing security issues, we hope that the fix won&#39;t impact the other considerations. Sometimes that&#39;s not possible though, and security wins out. For example, &quot;no . in @INC&quot;. <br/> <br/>This is not only &quot;fix security bugs&quot;, but also &quot;try and prevent security bugs in Perl&quot;. <br/> <br/> <br/>Reliability <br/> <br/>Once someone has written Perl code and it has been &quot;put into production&quot;, we should do our best to ensure that it continues to work when they upgrade to a new version of Perl.&Acirc;&nbsp;&Acirc;&nbsp;Perl has a reputation for backward compatibility, earned over decades.&Acirc;&nbsp;&Acirc;&nbsp;That reputation is valuable, and we should only spend that capital in return for something sufficiently valuable to warrant it. <br/> <br/>&Acirc;&nbsp;&Acirc;&nbsp;- Aim for backwards compatibility when introducing new features. <br/>&Acirc;&nbsp;&Acirc;&nbsp;- Fix bugs, while remembering that sometimes bugs become relied upon, and fixing those ones can break code. <br/>&Acirc;&nbsp;&Acirc;&nbsp;- Be mindful of the breakage of CPAN code, which is our best proxy for how proprietary code may break. <br/> <br/>This doesn&#39;t mean that we must be 100% backwards compatible and never break any CPAN modules, but that we should only deviate from that when we&#39;ve carefully considered the impact. If a change would break three twenty-year old modules on CPAN that no-one seems to use, that&#39;s a different proposition from breaking a module that&#39;s far up the CPAN River. <br/> <br/>Furthermore, if we do decide that it&#39;s ok to break something, we should try to reduce the inconvenience it causes by providing advance notice, clear documentation, and, when possible, tooling or other assistance. <br/> <br/>It&#39;s easy to think that perl is just about what you do in perl, but over the years perl has been used, and is still being used for a broad range of things. I think it would help us to have a shared picture of those, but that&#39;s for another day. <br/> <br/> <br/>Effectiveness <br/> <br/>This is about continuously evolving and improving Perl, to make the lives of active Perl developers better: increase productivity, prevent common bugs, improve performance, etc. <br/> <br/>Some of this is about filling gaps in the features provided by Perl, which developers may be used to from other languages. <br/> <br/>This can also be small incremental improvements in the language, particularly where we have the evidence to support them, for example where people regularly make the same mistake, or there&#39;s an commonly used idiom. To borrow a phrase from Nicholas, if we think something should be in the FAQ, then we should also consider whether it&#39;s something the language should provide. <br/> <br/>This might also be by including additional modules in the core. There are differing thoughts here: some want to see more batteries included, but every additional core module is additional maintenance and release work. <br/> <br/>When adding new features or feature bundles, we also need to think about all the existing code out there and how we help it bridge the gap without requiring a stressful flag-day effort. <br/> <br/> <br/>Growth <br/> <br/>Many of the features that we&#39;d like to see in Perl are things that have been provided by plenty of other languages for years. We&#39;re playing catch-up. Many of these features aren&#39;t likely to attract significant numbers of new developers, but the aggregate effect of them will hopefully bring us up to par. <br/> <br/>Considering the leaky bucket model, some of the things we can do for growth are really about reducing leakage. <br/> <br/>That said, there are no doubt changes we could make to give Perl an edge over other languages, some of which have been called for in recent discussions. But we have to remember the resources we have available and that we&#39;re a volunteer organisation. <br/> <br/>What will really attract new Perl developers in greater numbers is CPAN distributions for emerging domains. Lots of people have learned Python because of the machine learning support. There&#39;s a chicken and egg problem here, but it&#39;s not one for P5P to try and solve. <br/> <br/>It&#39;s also tempting to bundle Effectiveness and Growth together, but I think it&#39;s worth separating them, as (a) I think the things that will attract significant numbers of developers aren&#39;t the language, and (b) some significant changes to the language possibly would attract new developers, but at the cost of existing developers, which in general isn&#39;t a trade-off I think we should make. <br/> <br/> <br/>Final Thoughts <br/> <br/>These aren&#39;t gates, but an order in which we should consider things. It doesn&#39;t mean that we can&#39;t consider changes that will break things, but that we have to make an informed decision, and that some considerations are more important than others. A sexy new feature that might attract hordes of new developers won&#39;t be acceptable if it makes Perl less secure, or inconveniences significant numbers of our existing users or current developers. <br/> <br/>None of this is surprising or new. It&#39;s an attempt to write down what I think most people feel. Some of these ideas are already built-in to how new capabilities are rolled out, with feature guards, for example, and the &quot;use vN&quot; version bundles. <br/> <br/>So, should reliability of old code come ahead of the e of current developers? There&#39;s surely some existing perl code in the wild that no one cares about any more (let&#39;s call it &quot;abandoned code&quot;), and if we broke it, its owners wouldn&#39;t care. But we&#39;ve no way of identifying all the abandoned code, so it&#39;s unrealistic that we could define changes that would only break abandoned code. And if we tried this, then people would naturally worry that at some point in the future we might sacrifice their code&#39;s reliability to the new feature gods, and we&#39;d lose perhaps the strongest pillar of Perl&#39;s reputation. <br/> <br/>In addition to the priorities outlined here, we think there are principles that we apply as well. For example, in designing new language features, we should ensure they are consistent with the existing language. <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259782.html Sat, 10 Apr 2021 20:14:38 +0000 Perl 5 Commit Summary by Perl 5 commit summary Perl 5 commit summary, activity since Wednesday<br/><br/>Current branch blead<br/>3 commits. 3 unique authors. 3 unique committers.<br/>3 files changed, 17 insertions(+), 16 deletions(-)<br/><br/>Snapshot: http://github.com/Perl/perl5/tarball/d6b338e16ce63112<br/><br/> Add a comment where people might look for pp_grepwhile() to point out it liv<br/> Paul &quot;LeoNerd&quot; Evans 1 file changed, 2 insertions(+)<br/> https://github.com/Perl/perl5/commit/d6b338e16ce63112<br/><br/> charnames.t: Fix test names<br/> Karl Williamson 1 file changed, 5 insertions(+), 5 deletions(-)<br/> https://github.com/Perl/perl5/commit/f9dc267ffe1ac94a<br/><br/> Correct documentation of indent Style 2<br/> James E Keenan 1 file changed, 10 insertions(+), 11 deletions(-<br/> https://github.com/Perl/perl5/commit/1c48faa6f6d00e24<br/><br/>Current branch smoke-me/khw-locale<br/>213 commits. 1 unique author. 1 unique committer.<br/>18 files changed, 400 insertions(+), 300 deletions(-)<br/><br/>Snapshot: http://github.com/Perl/perl5/tarball/0913629a528ecc56<br/><br/> 27<br/> Karl Williamson 18 files changed, 642 insertions(+), 429 deletio<br/> https://github.com/Perl/perl5/commit/0913629a528ecc56<br/><br/> sv.c: Fix up a comment<br/> Karl Williamson 1 file changed, 5 insertions(+), 5 deletions(-)<br/> https://github.com/Perl/perl5/commit/878a70ce99d7c067<br/><br/> Kludge to get cygwin to compile<br/> Karl Williamson 1 file changed, 3 insertions(+)<br/> https://github.com/Perl/perl5/commit/b0fc739cf6d1ff72<br/><br/> patchlevel.h: White-space only: properly indent<br/> Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/f32a1d5552cf3e85<br/><br/> perl.h: Change macro name to be C conformant<br/> Karl Williamson 2 files changed, 12 insertions(+), 12 deletions(<br/> https://github.com/Perl/perl5/commit/6e05253581c3d2ca<br/><br/> XXX Configure strftime() is C89<br/> Karl Williamson 2 files changed, 1 insertion(+), 8 deletions(-)<br/> https://github.com/Perl/perl5/commit/c726307d477f619a<br/><br/> locale.c: Move code, white-space, comment only<br/> Karl Williamson 1 file changed, 167 insertions(+), 181 deletions<br/> https://github.com/Perl/perl5/commit/0550146093280407<br/><br/> locale.c: Add &#39;Lazy&#39; location changing<br/> Karl Williamson 2 files changed, 43 insertions(+), 15 deletions(<br/> https://github.com/Perl/perl5/commit/b7a16b7a663ee80e<br/><br/> intrpvar.h: Swap position of two defns; add comment<br/> Karl Williamson 1 file changed, 5 insertions(+), 2 deletions(-)<br/> https://github.com/Perl/perl5/commit/9476194aff98cdeb<br/><br/> locale.c: Rmv unused code<br/> Karl Williamson 3 files changed, 15 insertions(+), 29 deletions(<br/> https://github.com/Perl/perl5/commit/c41339cad9d7f1d0<br/><br/> l<br/> Karl Williamson 1 file changed, 10 insertions(+), 6 deletions(-)<br/> https://github.com/Perl/perl5/commit/00c7ab98f0ad94b5<br/><br/> XXX Temp dont use querylocale()<br/> Karl Williamson 1 file changed, 5 insertions(+)<br/> https://github.com/Perl/perl5/commit/5fab06b9edbbba2a<br/><br/> perlxs<br/> Karl Williamson 2 files changed, 475 insertions(+), 18 deletions<br/> https://github.com/Perl/perl5/commit/89f81c70b3eb991a<br/><br/> handy.h: Add layer for char classification/case change<br/> Karl Williamson 1 file changed, 99 insertions(+), 38 deletions(-<br/> https://github.com/Perl/perl5/commit/d167cbf3ff419407<br/><br/> f save_to_buffer ignore return<br/> Karl Williamson 2 files changed, 2 insertions(+), 4 deletions(-)<br/> https://github.com/Perl/perl5/commit/2e2f743cfac386e3<br/><br/> locale.c: windows DEBUG stmts<br/> Karl Williamson 1 file changed, 5 insertions(+), 9 deletions(-)<br/> https://github.com/Perl/perl5/commit/9daaa05c552bbbd1<br/><br/> lib/locale.t FILE debug<br/> Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/4c25b59da8faaccf<br/><br/> Revert &quot;PLcurlocales&quot;<br/> Karl Williamson 4 files changed, 17 insertions(+), 15 deletions(<br/> https://github.com/Perl/perl5/commit/1cfd12a3220673f8<br/><br/> PLcurlocales<br/> Karl Williamson 4 files changed, 15 insertions(+), 17 deletions(<br/> https://github.com/Perl/perl5/commit/824321d0f6d90e1f<br/><br/> l<br/> Karl Williamson 1 file changed, 43 insertions(+), 7 deletions(-)<br/> https://github.com/Perl/perl5/commit/6db212a81254c71c<br/><br/> Add pTHX to locale_thread_init()<br/> Karl Williamson 4 files changed, 4 insertions(+), 6 deletions(-)<br/> https://github.com/Perl/perl5/commit/585cc43995fd7eca<br/><br/> XXX loc_tools: debug, white space<br/> Karl Williamson 1 file changed, 11 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/dd84f36244e9e87d<br/><br/> locale.c: Change a branch into an assert<br/> Karl Williamson 1 file changed, 1 insertion(+), 5 deletions(-)<br/> https://github.com/Perl/perl5/commit/08bcf204c9e81aff<br/><br/> vutil.c: Simplify locale handling<br/> Karl Williamson 2 files changed, 9 insertions(+), 60 deletions(-<br/> https://github.com/Perl/perl5/commit/a0c622ea8e7a897a<br/><br/> vutil.c: Clean up white space<br/> Karl Williamson 2 files changed, 512 insertions(+), 515 deletion<br/> https://github.com/Perl/perl5/commit/f0fc4eb68156ca51<br/><br/> XXX run/locale.t temp win<br/> Karl Williamson 1 file changed, 3 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/dd1b31f12cba4593<br/><br/> t/run/locale.t: Move init stmt<br/> Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/e7be48585fa637a9<br/><br/> t/run/locale.t<br/> Karl Williamson 1 file changed, 3 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/ecf43a52b2cb5c4d<br/><br/> Make DEBUGGING the default on CI<br/> Karl Williamson 1 file changed, 7 insertions(+), 7 deletions(-)<br/> https://github.com/Perl/perl5/commit/f6e3e6f8ed002bc8<br/><br/> XXX locale.c: Kludge because C obj getting destroyed<br/> Karl Williamson 1 file changed, 9 insertions(+)<br/> https://github.com/Perl/perl5/commit/a8cc8422567cd216<br/><br/> locks<br/> Karl Williamson 3 files changed, 96 insertions(+), 40 deletions(<br/> https://github.com/Perl/perl5/commit/c85d4ec3c921ed37<br/><br/> Notes<br/> Karl Williamson 9 files changed, 35 insertions(+), 4 deletions(-<br/> https://github.com/Perl/perl5/commit/7c3cd3f4ed2dadcd<br/><br/> XXX perl.h: Debugging mutex lock&#39;<br/> Karl Williamson 1 file changed, 17 insertions(+)<br/> https://github.com/Perl/perl5/commit/1bdda38665081401<br/><br/> XXX thread.h Save errno around lock/unlock<br/> Karl Williamson 1 file changed, 4 insertions(+)<br/> https://github.com/Perl/perl5/commit/5b8877a252926135<br/><br/> thread.h: White-space, braces only<br/> Karl Williamson 1 file changed, 20 insertions(+), 17 deletions(-<br/> https://github.com/Perl/perl5/commit/09d009c132e78048<br/><br/> XXX check with freebsd: hints/freebsd.sh<br/> Karl Williamson 1 file changed, 6 insertions(+), 10 deletions(-)<br/> https://github.com/Perl/perl5/commit/d5e60a62fa14d1b1<br/><br/> XXX check if using ppport IO.xs: Remove fallback code furnished by ppport<br/> Karl Williamson 2 files changed, 1 insertion(+), 43 deletions(-)<br/> https://github.com/Perl/perl5/commit/c803ff65565686a9<br/><br/> XXX incomplete perlhacktips:<br/> Karl Williamson 1 file changed, 25 insertions(+), 26 deletions(-<br/> https://github.com/Perl/perl5/commit/07f86d330caacac0<br/><br/> Time-Piece: Use isUPPER, not isupper<br/> Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/3e5444fb26511c01<br/><br/> Time-Piece: Use isDIGIT, not isdigit<br/> Karl Williamson 1 file changed, 18 insertions(+), 18 deletions(-<br/> https://github.com/Perl/perl5/commit/725ef40094e285d0<br/><br/> Time-Piece: Use isSPACE, not isspace<br/> Karl Williamson 1 file changed, 20 insertions(+), 20 deletions(-<br/> https://github.com/Perl/perl5/commit/710de70f4b34c1b8<br/><br/> Time-Piece: Use foldEQ_locale() if available<br/> Karl Williamson 1 file changed, 18 insertions(+), 12 deletions(-<br/> https://github.com/Perl/perl5/commit/76a187d06a8660c7<br/><br/> XXX cpan PR Time-Piece: Add locks<br/> Karl Williamson 2 files changed, 74 insertions(+), 8 deletions(-<br/> https://github.com/Perl/perl5/commit/63cf69a24fc68d37<br/><br/> os2: Use many reader lock instead of exclusive<br/> Karl Williamson 1 file changed, 3 insertions(+), 3 deletions(-)<br/> https://github.com/Perl/perl5/commit/f9f93a90a98e482f<br/><br/> cygwin<br/> Karl Williamson 1 file changed, 38 insertions(+), 35 deletions(-<br/> https://github.com/Perl/perl5/commit/30c2ab25d71e17cd<br/><br/> util.c: Add locks around strftime() calls<br/> Karl Williamson 1 file changed, 4 insertions(+)<br/> https://github.com/Perl/perl5/commit/eac330c37f4b80ea<br/><br/> util.c: mktime needs to run under a mutex<br/> Karl Williamson 1 file changed, 2 insertions(+)<br/> https://github.com/Perl/perl5/commit/3afdce047a213d82<br/><br/> POSIX.xs env locks, check file for more<br/> Karl Williamson 1 file changed, 15 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/3254756dacef9409<br/><br/> win32.c: Add mutexes around some calls<br/> Karl Williamson 1 file changed, 12 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/0261bc2bdce8758c<br/><br/> XXX need to StructCopy pp_sys mutexes<br/> Karl Williamson 1 file changed, 14 insertions(+), 2 deletions(-)<br/> https://github.com/Perl/perl5/commit/c3eb7f51c805aedf<br/><br/> time64.c: Remove no longer needed code<br/> Karl Williamson 1 file changed, 34 deletions(-)<br/> https://github.com/Perl/perl5/commit/d2d069a1b182af78<br/><br/> perl.h: Finish implementing combo ENV/LOCALE mutexes<br/> Karl Williamson 2 files changed, 164 insertions(+), 7 deletions(<br/> https://github.com/Perl/perl5/commit/a50a35b00399bbfb<br/><br/> perl.h: Move some statements<br/> Karl Williamson 1 file changed, 6 insertions(+), 6 deletions(-)<br/> https://github.com/Perl/perl5/commit/80bd7c9d9a14f707<br/><br/> Change ENV/LOCALE locking read macro names<br/> Karl Williamson 3 files changed, 8 insertions(+), 8 deletions(-)<br/> https://github.com/Perl/perl5/commit/b1d36e0b5857e1b6<br/><br/> Remove ENV_LOCALE_LOCK/UNLOCK macros<br/> Karl Williamson 2 files changed, 9 insertions(+), 18 deletions(-<br/> https://github.com/Perl/perl5/commit/67c95488c4fc7891<br/><br/> perl.h: Add #define for gwENVr_LOCALEr_UNLOCK<br/> Karl Williamson 1 file changed, 52 insertions(+), 2 deletions(-)<br/> https://github.com/Perl/perl5/commit/8f76c50e91b076da<br/><br/> XXX prob drop; done before anything so no races<br/> Karl Williamson 1 file changed, 5 insertions(+)<br/> https://github.com/Perl/perl5/commit/e979451544283b81<br/><br/> locale.c comments<br/> Karl Williamson 1 file changed, 8 insertions(+)<br/> https://github.com/Perl/perl5/commit/a7d87aa339d9a04f<br/><br/> XXX temp debug? locale.c, inline.h:foldEQ_locale<br/> Karl Williamson 2 files changed, 21 insertions(+), 2 deletions(-<br/> https://github.com/Perl/perl5/commit/7ff1155d75bd6724<br/><br/> Make fc(), /i thread-safe on participating platforms<br/> Karl Williamson 8 files changed, 6 insertions(+), 90 deletions(-<br/> https://github.com/Perl/perl5/commit/49578708a1078e8c<br/><br/> XXX pp.c: do %g print under mutex,<br/> Karl Williamson 1 file changed, 8 insertions(+), 2 deletions(-)<br/> https://github.com/Perl/perl5/commit/a0f5d2ff1aa84100<br/><br/> XXX make sure comments get moved appropriately perl.h: Remove now empty bloc<br/> Karl Williamson 1 file changed, 34 deletions(-)<br/> https://github.com/Perl/perl5/commit/c969e5d637ffe2eb<br/><br/> locale.c: Mitigate unsafe threaded locales<br/> Karl Williamson 4 files changed, 154 insertions(+), 2 deletions(<br/> https://github.com/Perl/perl5/commit/fe19f9496f017b45<br/><br/> locale.c: Move #define to perl.h; use it elsewhere<br/> Karl Williamson 6 files changed, 16 insertions(+), 13 deletions(<br/> https://github.com/Perl/perl5/commit/1a552ef276506635<br/><br/> perl.h: Move LOCALE_READ_LOCK #definition<br/> Karl Williamson 1 file changed, 6 insertions(+), 8 deletions(-)<br/> https://github.com/Perl/perl5/commit/e286f0f6702c50a4<br/><br/> perl.h: Move #defining SETLOCALE_LOCK<br/> Karl Williamson 1 file changed, 8 insertions(+), 13 deletions(-)<br/> https://github.com/Perl/perl5/commit/663d70dfeac17763<br/><br/> XXX perlembed Add PORCELAIN_SETLOCALE_LOCK/UNLOCK<br/> Karl Williamson 2 files changed, 31 insertions(+), 2 deletions(-<br/> https://github.com/Perl/perl5/commit/b98b2c353a0d24a1<br/><br/> perl.h: Remove LOCALECONV_LOCK<br/> Karl Williamson 2 files changed, 5 insertions(+), 20 deletions(-<br/> https://github.com/Perl/perl5/commit/8f1036c9cfa4a41c<br/><br/> perl.h: Remove NL_LANGINFO_LOCK<br/> Karl Williamson 2 files changed, 3 insertions(+), 12 deletions(-<br/> https://github.com/Perl/perl5/commit/4238fc0085a62c95<br/><br/> Redefine the POSIX.xs locale macros using prev commit<br/> Karl Williamson 1 file changed, 10 insertions(+), 22 deletions(-<br/> https://github.com/Perl/perl5/commit/46dcdb3895cd2118<br/><br/> Add locale macro to wrap static-space-using fncs<br/> Karl Williamson 1 file changed, 24 insertions(+)<br/> https://github.com/Perl/perl5/commit/75595df5fba94923<br/><br/> Use general locale mutex for numeric operations<br/> Karl Williamson 6 files changed, 18 insertions(+), 102 deletions<br/> https://github.com/Perl/perl5/commit/759d8a0494b68de1<br/><br/> Make the locale mutex a general semaphore<br/> Karl Williamson 6 files changed, 90 insertions(+), 31 deletions(<br/> https://github.com/Perl/perl5/commit/22afd6a89ad23dcc<br/><br/> perl.h: Reorder cpp branches<br/> Karl Williamson 1 file changed, 3 insertions(+), 3 deletions(-)<br/> https://github.com/Perl/perl5/commit/7a4e184927dcbfb9<br/><br/> perl.h: Move some code around<br/> Karl Williamson 1 file changed, 39 insertions(+), 27 deletions(-<br/> https://github.com/Perl/perl5/commit/617bc41a22a24191<br/><br/> Mark certain mutex lock macros as private<br/> Karl Williamson 3 files changed, 22 insertions(+), 22 deletions(<br/> https://github.com/Perl/perl5/commit/cb17eac009264a33<br/><br/> locale.c: Print code point in hex, not decimal<br/> Karl Williamson 1 file changed, 10 insertions(+), 10 deletions(-<br/> https://github.com/Perl/perl5/commit/ad61e705cf88634e<br/><br/> locale.c: Add debug statement for collation failure<br/> Karl Williamson 1 file changed, 4 insertions(+)<br/> https://github.com/Perl/perl5/commit/17a36ffbf0ac5719<br/><br/> locale.c: Improve debugging for mem_collxfrm()<br/> Karl Williamson 4 files changed, 21 insertions(+), 26 deletions(<br/> https://github.com/Perl/perl5/commit/4ae807e39fe2c0c2<br/><br/> XXXdelta Fix POSIX::strxfrm()<br/> Karl Williamson 5 files changed, 61 insertions(+), 21 deletions(<br/> https://github.com/Perl/perl5/commit/343aa22384adfa61<br/><br/> Change name of internal function<br/> Karl Williamson 6 files changed, 29 insertions(+), 29 deletions(<br/> https://github.com/Perl/perl5/commit/7314273410727d53<br/><br/> locale.c: Use strxfrm_l() if available<br/> Karl Williamson 1 file changed, 25 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/031f5a1516e86e7d<br/><br/> XXX temp: Windows debug<br/> Karl Williamson 1 file changed, 4 insertions(+)<br/> https://github.com/Perl/perl5/commit/6217fe9dfa7f8f01<br/><br/> Configure: strxfrm_l<br/> Karl Williamson 14 files changed, 42 insertions(+), 16 deletions<br/> https://github.com/Perl/perl5/commit/c775cc4b14d189a5<br/><br/> locale.c: strxfrm() requires LC_CTYPE eq LC_COLLATE<br/> Karl Williamson 1 file changed, 13 insertions(+)<br/> https://github.com/Perl/perl5/commit/8104a2c97144975a<br/><br/> locale.c: Don&#39;t assume LC_CTYPE, LC_COLLATE are same<br/> Karl Williamson 1 file changed, 13 insertions(+)<br/> https://github.com/Perl/perl5/commit/de8245bc3a640634<br/><br/> locale.c: Add check that strxfrm didn&#39;t fail<br/> Karl Williamson 1 file changed, 14 insertions(+), 5 deletions(-)<br/> https://github.com/Perl/perl5/commit/27e800138a99b5aa<br/><br/> locale.c: Use standard fold table for C locale<br/> Karl Williamson 1 file changed, 20 insertions(+), 15 deletions(-<br/> https://github.com/Perl/perl5/commit/dd9d481d7ee96e18<br/><br/> locale.c: Change assert() into STATIC_ASSERT()<br/> Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/1ca0e4b0c89b0eba<br/><br/> locale.c: Refactor a static function<br/> Karl Williamson 1 file changed, 41 insertions(+), 29 deletions(-<br/> https://github.com/Perl/perl5/commit/a249603eba6d4191<br/><br/> locale.c: Reorder &#39;if&#39; branches<br/> Karl Williamson 1 file changed, 4 insertions(+), 4 deletions(-)<br/> https://github.com/Perl/perl5/commit/bcbf77a5e18634e5<br/><br/> locale.c: Reorder code, rmv unneeded conditional<br/> Karl Williamson 1 file changed, 6 insertions(+), 6 deletions(-)<br/> https://github.com/Perl/perl5/commit/a1dff3aa1277cb5c<br/><br/> locale.c: Add some asserts<br/> Karl Williamson 1 file changed, 4 insertions(+)<br/> https://github.com/Perl/perl5/commit/243592af833d83ed<br/><br/> XXX PORCELAIN_SET not yet defined locale.c: Move DEBUG location info<br/> Karl Williamson 1 file changed, 70 insertions(+), 89 deletions(-<br/> https://github.com/Perl/perl5/commit/2050332ab4ee7ccd<br/><br/> locale.c: Use new mechanism to save/restore errno<br/> Karl Williamson 1 file changed, 5 insertions(+), 15 deletions(-)<br/> https://github.com/Perl/perl5/commit/b37f67ce18de8bb0<br/><br/> Swap the ordering of two locale category indices<br/> Karl Williamson 2 files changed, 22 insertions(+), 22 deletions(<br/> https://github.com/Perl/perl5/commit/015473ae599d205b<br/><br/> intrpvar.h: Initialize a variable<br/> Karl Williamson 1 file changed, 3 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/4523cf4a386a4c05<br/><br/> locale.c: Cache the current LC_CTYPE locale name<br/> Karl Williamson 6 files changed, 42 insertions(+), 4 deletions(-<br/> https://github.com/Perl/perl5/commit/da1ce703e92c82a1<br/><br/> locale.c: Omit an extra copy<br/> Karl Williamson 1 file changed, 2 insertions(+), 2 deletions(-)<br/> https://github.com/Perl/perl5/commit/c498b5740aa2a6ca<br/><br/> Revamp switch_to_global_locale()<br/> Karl Williamson 1 file changed, 36 insertions(+), 13 deletions(-<br/> https://github.com/Perl/perl5/commit/f7798e76b483e738<br/><br/> locale.c: Clean up thread_locale_init()<br/> Karl Williamson 1 file changed, 24 insertions(+), 10 deletions(-<br/> https://github.com/Perl/perl5/commit/c8e12a1a55c32efa<br/><br/> locale.c: Revamp sync_locale()<br/> Karl Williamson 1 file changed, 73 insertions(+), 55 deletions(-<br/> https://github.com/Perl/perl5/commit/a4d4a5e93704af5c<br/><br/> Add a common locale panic macro and functions<br/> Karl Williamson 5 files changed, 69 insertions(+), 33 deletions(<br/> https://github.com/Perl/perl5/commit/4be31fb8fa45d193<br/><br/> Don&#39;t discard locale info in starting P2008<br/> Karl Williamson 1 file changed, 24 insertions(+), 5 deletions(-)<br/> https://github.com/Perl/perl5/commit/8c97ea61b5ed2076<br/><br/> locale.c: Rmv no longer used code; UTF8ness cache<br/> Karl Williamson 7 files changed, 767 deletions(-)<br/> https://github.com/Perl/perl5/commit/a8f3b75b73b85102<br/><br/> mg.c: White-space only<br/> Karl Williamson 1 file changed, 17 insertions(+), 16 deletions(-<br/> https://github.com/Perl/perl5/commit/e8ada597fc59e795<br/><br/> Move utf8ness calc for $! into locale.c from mg.c<br/> Karl Williamson 6 files changed, 98 insertions(+), 54 deletions(<br/> https://github.com/Perl/perl5/commit/a826f81079ece273<br/><br/> Avoid mojibake in &quot;$!&quot;<br/> Karl Williamson 1 file changed, 144 insertions(+), 128 deletions<br/> https://github.com/Perl/perl5/commit/63613970fa7e6ba6<br/><br/> locale.c: Refactor #ifdef&#39;s for clarity<br/> Karl Williamson 4 files changed, 96 insertions(+), 50 deletions(<br/> https://github.com/Perl/perl5/commit/83b43859e01260cd<br/><br/> locale.c: Use Strerror(), not strerror()<br/> Karl Williamson 1 file changed, 3 insertions(+), 3 deletions(-)<br/> https://github.com/Perl/perl5/commit/516d20a2b53968e9<br/><br/> locale.c: Add fallbacks if no mbtowc()<br/> Karl Williamson 1 file changed, 113 insertions(+), 4 deletions(-<br/> https://github.com/Perl/perl5/commit/708a32b7677cb0bc<br/><br/> XXXdelta Add Perl_langinfo8()<br/> Karl Williamson 4 files changed, 102 insertions(+), 101 deletion<br/> https://github.com/Perl/perl5/commit/23dc9fd218166bcd<br/><br/> locale.c: Add utf8ness return param to static fcn<br/> Karl Williamson 4 files changed, 70 insertions(+), 30 deletions(<br/> https://github.com/Perl/perl5/commit/4fa0000fdd19a4e9<br/><br/> XXXdelta Add my_strftime8()<br/> Karl Williamson 5 files changed, 72 insertions(+), 14 deletions(<br/> https://github.com/Perl/perl5/commit/284f96ce21c77d69<br/><br/> locale.c: Fix windows bug with broken localeconv()<br/> Karl Williamson 1 file changed, 16 insertions(+), 7 deletions(-)<br/> https://github.com/Perl/perl5/commit/9ef3f57402a479de<br/><br/> locale.c: Collapse duplicate logic into one instance<br/> Karl Williamson 4 files changed, 160 insertions(+), 162 deletion<br/> https://github.com/Perl/perl5/commit/da80b4f6abe4ac5d<br/><br/> XXX perldelta Move POSIX::localeconv() logic to locale.c<br/> Karl Williamson 5 files changed, 403 insertions(+), 204 deletion<br/> https://github.com/Perl/perl5/commit/f301c8ead46343e1<br/><br/> locale.c: Add fcn for UTF8ness determination<br/> Karl Williamson 4 files changed, 113 insertions(+)<br/> https://github.com/Perl/perl5/commit/c08958a540e7c385<br/><br/> locale.c: Add is_locale_utf8()<br/> Karl Williamson 4 files changed, 42 insertions(+), 3 deletions(-<br/> https://github.com/Perl/perl5/commit/f5c9f6f695fdc20c<br/><br/> New signature for static fcn my_langinfo()<br/> Karl Williamson 4 files changed, 310 insertions(+), 145 deletion<br/> https://github.com/Perl/perl5/commit/ea8ab0e0ae186e45<br/><br/> locale.c: Improve non-nl_langinfo() CODESET calc<br/> Karl Williamson 2 files changed, 76 insertions(+), 43 deletions(<br/> https://github.com/Perl/perl5/commit/7148f9237feb254a<br/><br/> locale.c: Add static fcn to analyze locale codeset<br/> Karl Williamson 4 files changed, 30 insertions(+)<br/> https://github.com/Perl/perl5/commit/9faabbeb395441d1<br/><br/> locale.c: langinfo: Use Windows fcn to find CODESET<br/> Karl Williamson 1 file changed, 15 insertions(+), 2 deletions(-)<br/> https://github.com/Perl/perl5/commit/39991c8170ca45f1<br/><br/> locale.c: Make static fcn reentrant<br/> Karl Williamson 4 files changed, 88 insertions(+), 49 deletions(<br/> https://github.com/Perl/perl5/commit/cf071e9143f3dd13<br/><br/> locale.c: Use a scratch buf; instead of reusing old<br/> Karl Williamson 1 file changed, 29 insertions(+), 33 deletions(-<br/> https://github.com/Perl/perl5/commit/e1027f5a21b83bce<br/><br/> locale.c: Don&#39;t change locale if already there<br/> Karl Williamson 1 file changed, 37 insertions(+)<br/> https://github.com/Perl/perl5/commit/f373ee2957400804<br/><br/> locale.c: Rmv no longer used param from static fnc<br/> Karl Williamson 3 files changed, 42 insertions(+), 24 deletions(<br/> https://github.com/Perl/perl5/commit/dc9e3e8e681b94ae<br/><br/> locale.c: Don&#39;t ask a static fcn to be inlined<br/> Karl Williamson 3 files changed, 3 insertions(+), 5 deletions(-)<br/> https://github.com/Perl/perl5/commit/69d81b8a7954ce81<br/><br/> locale.c: Don&#39;t add CP to Windows code page names<br/> Karl Williamson 1 file changed, 6 insertions(+), 28 deletions(-)<br/> https://github.com/Perl/perl5/commit/5fd9837ab0984548<br/><br/> locale.c: Fix currency symbol derivation<br/> Karl Williamson 1 file changed, 13 insertions(+), 20 deletions(-<br/> https://github.com/Perl/perl5/commit/0914c2725ec95ee4<br/><br/> locale.c: Rmv redundant cBOOL()<br/> Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/b6d8ad5eda28d817<br/><br/> locale.c: Use typedef to simplify<br/> Karl Williamson 1 file changed, 6 insertions(+), 8 deletions(-)<br/> https://github.com/Perl/perl5/commit/2d80f4020c18043f<br/><br/> locale.c: Extend a static function<br/> Karl Williamson 3 files changed, 6 insertions(+), 4 deletions(-)<br/> https://github.com/Perl/perl5/commit/41054c8742daf007<br/><br/> locale.c: Shorten static function name<br/> Karl Williamson 4 files changed, 18 insertions(+), 18 deletions(<br/> https://github.com/Perl/perl5/commit/28e7ab08d9af3a90<br/><br/> locale.c: Rmv reimplementation of my_strftime()<br/> Karl Williamson 1 file changed, 67 insertions(+), 141 deletions(<br/> https://github.com/Perl/perl5/commit/a55d25fff437d83a<br/><br/> locale.c: Return defaults for uncomputable langinfo items<br/> Karl Williamson 4 files changed, 164 insertions(+), 40 deletions<br/> https://github.com/Perl/perl5/commit/216be4c9d5f7c3f2<br/><br/> locale.c: Add two #defines<br/> Karl Williamson 1 file changed, 15 insertions(+), 8 deletions(-)<br/> https://github.com/Perl/perl5/commit/1b5ac058a037d431<br/><br/> locale.c: Make statics of repeated string constants<br/> Karl Williamson 1 file changed, 10 insertions(+), 5 deletions(-)<br/> https://github.com/Perl/perl5/commit/b4fb92408b75a21e<br/><br/> locale.c: Reorder cases in a switch<br/> Karl Williamson 1 file changed, 61 insertions(+), 60 deletions(-<br/> https://github.com/Perl/perl5/commit/97bb5966f1da0641<br/><br/> Move code from POSIX.xs to locale.c<br/> Karl Williamson 5 files changed, 75 insertions(+), 61 deletions(<br/> https://github.com/Perl/perl5/commit/b72a96664116d724<br/><br/> POSIX.xs: White-space only<br/> Karl Williamson 1 file changed, 28 insertions(+), 27 deletions(-<br/> https://github.com/Perl/perl5/commit/9f45066f7d48a80b<br/><br/> POSIX.xs: Use macro to reduce complexity<br/> Karl Williamson 1 file changed, 30 insertions(+), 24 deletions(-<br/> https://github.com/Perl/perl5/commit/ac89108dcf4c4956<br/><br/> locale.c: Separate out two Win fcns from a larger one<br/> Karl Williamson 1 file changed, 56 insertions(+), 26 deletions(-<br/> https://github.com/Perl/perl5/commit/a913545732aed9b7<br/><br/> locale.c: Add DEBUGGING information<br/> Karl Williamson 4 files changed, 52 insertions(+), 43 deletions(<br/> https://github.com/Perl/perl5/commit/b519f161fd63bdba<br/><br/> locale.c: Add fcn to hide edge case undefined behavior<br/> Karl Williamson 9 files changed, 48 insertions(+), 23 deletions(<br/> https://github.com/Perl/perl5/commit/d077e613edfcb0e1<br/><br/> sv.c: Duplicate more variables during cloning<br/> Karl Williamson 1 file changed, 7 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/dcb018e41735cba6<br/><br/> Split off setting locale to &quot;&quot; from S_emulate_setlocale<br/> Karl Williamson 4 files changed, 82 insertions(+), 105 deletions<br/> https://github.com/Perl/perl5/commit/2d6091746c13661e<br/><br/> locale.c: locale &quot;&quot; can be disparate<br/> Karl Williamson 1 file changed, 2 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/37c63f86fe48e64c<br/><br/> locale.c: Split ancillary from S_emulate_setlocale<br/> Karl Williamson 4 files changed, 103 insertions(+), 49 deletions<br/> https://github.com/Perl/perl5/commit/cac993d577f38fd7<br/><br/> locale.c: Clean up handling of a glibc bug<br/> Karl Williamson 1 file changed, 29 insertions(+), 16 deletions(-<br/> https://github.com/Perl/perl5/commit/26bc50d39ff05b35<br/><br/> locale.c: Change internal variable name<br/> Karl Williamson 3 files changed, 23 insertions(+), 23 deletions(<br/> https://github.com/Perl/perl5/commit/ca770788e4b604aa<br/><br/> locale.c: Split aggregate LC_ALL from emulate_setlocale<br/> Karl Williamson 4 files changed, 139 insertions(+), 106 deletion<br/> https://github.com/Perl/perl5/commit/8339f38e96865ccc<br/><br/> locale.c: Use setlocale() for init, not P2008<br/> Karl Williamson 1 file changed, 17 insertions(+), 7 deletions(-)<br/> https://github.com/Perl/perl5/commit/0fe46f92e78f970a<br/><br/> locale.c: Refactor some derived #defines<br/> Karl Williamson 1 file changed, 7 insertions(+), 7 deletions(-)<br/> https://github.com/Perl/perl5/commit/a41dd037e72acb15<br/><br/> XXX drop stdize_locale: #if 0, enabled even for emulate<br/> Karl Williamson 1 file changed, 36 insertions(+), 2 deletions(-)<br/> https://github.com/Perl/perl5/commit/43328133d8322680<br/><br/> locale.c: Generalize stdize_locale()<br/> Karl Williamson 8 files changed, 168 insertions(+), 46 deletions<br/> https://github.com/Perl/perl5/commit/731701144e6c9ff6<br/><br/> Make three locale PL_ strings const char*<br/> Karl Williamson 4 files changed, 6 insertions(+), 6 deletions(-)<br/> https://github.com/Perl/perl5/commit/5808b3eec7809e06<br/><br/> locale.c: querylocale() doesn&#39;t work on LC_ALL<br/> Karl Williamson 5 files changed, 187 insertions(+), 99 deletions<br/> https://github.com/Perl/perl5/commit/eb53fd864f322bb5<br/><br/> locale.c: Create new convenience macro<br/> Karl Williamson 2 files changed, 33 insertions(+), 8 deletions(-<br/> https://github.com/Perl/perl5/commit/e090e44cf7e437f7<br/><br/> perl.h: Expand scope of cpp conditional<br/> Karl Williamson 1 file changed, 3 insertions(+), 3 deletions(-)<br/> https://github.com/Perl/perl5/commit/52a559cb84b0c738<br/><br/> locale.c: Remove exploratory code<br/> Karl Williamson 1 file changed, 47 deletions(-)<br/> https://github.com/Perl/perl5/commit/8cb3e4d29835d3f2<br/><br/> locale.c: Use low level macros at low level<br/> Karl Williamson 1 file changed, 12 insertions(+), 10 deletions(-<br/> https://github.com/Perl/perl5/commit/8b8454959985ae7e<br/><br/> Perl_setlocale(): Same code for all param2 == NULL<br/> Karl Williamson 1 file changed, 27 insertions(+), 23 deletions(-<br/> https://github.com/Perl/perl5/commit/98eae43c7fbb5437<br/><br/> locale.c: Use a function table to simplify code<br/> Karl Williamson 4 files changed, 77 insertions(+), 76 deletions(<br/> https://github.com/Perl/perl5/commit/622cec1e89556118<br/><br/> locale.c: Add panic check/message<br/> Karl Williamson 4 files changed, 59 insertions(+), 3 deletions(-<br/> https://github.com/Perl/perl5/commit/04061a03b7576f3f<br/><br/> locale.c: Add setlocale() return context macros<br/> Karl Williamson 1 file changed, 52 insertions(+), 35 deletions(-<br/> https://github.com/Perl/perl5/commit/cbc7f8b7de190ca6<br/><br/> locale.c: Add a convenience #define<br/> Karl Williamson 1 file changed, 4 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/ed656d43282026d2<br/><br/> locale.c: Generalize certain Win32 calls<br/> Karl Williamson 1 file changed, 12 insertions(+), 12 deletions(-<br/> https://github.com/Perl/perl5/commit/ec5a3e9182f88155<br/><br/> locale.c: Create new macros for just querying locale<br/> Karl Williamson 1 file changed, 29 insertions(+), 27 deletions(-<br/> https://github.com/Perl/perl5/commit/c6b2681a7ac5ee03<br/><br/> locale.c: #define some macros in terms of a base one<br/> Karl Williamson 1 file changed, 5 insertions(+), 3 deletions(-)<br/> https://github.com/Perl/perl5/commit/b450da4b6838fea5<br/><br/> locale.c: Remove spaces around a &#39;##&#39; preprocessor directive<br/> Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/42015f2860dc8e0a<br/><br/> locale.c: Outdent previous commit<br/> Karl Williamson 1 file changed, 98 insertions(+), 98 deletions(-<br/> https://github.com/Perl/perl5/commit/7b46f84f7150ad74<br/><br/> locale.c: Separate query part of emulate_setlocale()<br/> Karl Williamson 4 files changed, 66 insertions(+), 58 deletions(<br/> https://github.com/Perl/perl5/commit/f72e0889a5b208af<br/><br/> locale.c: Move fcn within file<br/> Karl Williamson 1 file changed, 42 insertions(+), 42 deletions(-<br/> https://github.com/Perl/perl5/commit/fdce26def412a782<br/><br/> locale.c: Comment clarifications, white space<br/> Karl Williamson 1 file changed, 482 insertions(+), 390 deletions<br/> https://github.com/Perl/perl5/commit/db7e1f16d9fa4ade<br/><br/> locale.c: Move unreachable code<br/> Karl Williamson 1 file changed, 6 insertions(+), 8 deletions(-)<br/> https://github.com/Perl/perl5/commit/d74241d0efd50ecf<br/><br/> locale.c: Simplify S_category_name<br/> Karl Williamson 3 files changed, 20 insertions(+), 39 deletions(<br/> https://github.com/Perl/perl5/commit/41f45d7384536be8<br/><br/> locale.c: Change S_emulate_setlocale name and sig<br/> Karl Williamson 4 files changed, 26 insertions(+), 50 deletions(<br/> https://github.com/Perl/perl5/commit/9438e7c6b2eed14c<br/><br/> locale.c: Use get_category_index()<br/> Karl Williamson 4 files changed, 36 insertions(+), 37 deletions(<br/> https://github.com/Perl/perl5/commit/c0f25da769377e07<br/><br/> locale.c: Create S_get_category_index()<br/> Karl Williamson 4 files changed, 60 insertions(+), 6 deletions(-<br/> https://github.com/Perl/perl5/commit/6bf59ad12d35be6f<br/><br/> locale.c: Cast return of setlocale() to const<br/> Karl Williamson 1 file changed, 2 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/becbcb0e208c965c<br/><br/> locale.c: Change macro name<br/> Karl Williamson 1 file changed, 17 insertions(+), 17 deletions(-<br/> https://github.com/Perl/perl5/commit/5b2895564b78dfe8<br/><br/> Regularize HAS_POSIX_2008_LOCALE, USE_POSIX_2008_LOCALE<br/> Karl Williamson 8 files changed, 12 insertions(+), 25 deletions(<br/> https://github.com/Perl/perl5/commit/46794438cf6c2183<br/><br/> Add USE_LOCALE_THREADS #define<br/> Karl Williamson 3 files changed, 15 insertions(+), 10 deletions(<br/> https://github.com/Perl/perl5/commit/8c7ae2cf36018601<br/><br/> Mark newly moved symbols as private<br/> Karl Williamson 2 files changed, 121 insertions(+), 121 deletion<br/> https://github.com/Perl/perl5/commit/5c90a7e174cdfd5f<br/><br/> Move some locale.c #defines to perl.h<br/> Karl Williamson 2 files changed, 83 insertions(+), 82 deletions(<br/> https://github.com/Perl/perl5/commit/82ddfb04d5aa4172<br/><br/> locale.c: Declare three static arrays to be so.<br/> Karl Williamson 1 file changed, 3 insertions(+), 3 deletions(-)<br/> https://github.com/Perl/perl5/commit/71d93b2465f130d3<br/><br/> regexec.c: Refactor switch default()<br/> Karl Williamson 1 file changed, 5 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/916d7a3ab98b18c3<br/><br/> regexec.c: Improve code<br/> Karl Williamson 1 file changed, 19 insertions(+), 16 deletions(-<br/> https://github.com/Perl/perl5/commit/521476b3178bf7fd<br/><br/> handy.h: Add isCASED_LC<br/> Karl Williamson 1 file changed, 4 insertions(+)<br/> https://github.com/Perl/perl5/commit/12d9ded49ff66719<br/><br/> XXX SEE IF WORKS handy.h: Change Windows macros<br/> Karl Williamson 1 file changed, 9 insertions(+), 8 deletions(-)<br/> https://github.com/Perl/perl5/commit/347428db3ee67c56<br/><br/> locale.c: Use new macros from the prev commit<br/> Karl Williamson 2 files changed, 34 insertions(+), 44 deletions(<br/> https://github.com/Perl/perl5/commit/5587c6ea0389c932<br/><br/> handy.h: Add wrapper layer macros for isalnum() ...<br/> Karl Williamson 1 file changed, 59 insertions(+), 44 deletions(-<br/> https://github.com/Perl/perl5/commit/7852b1b6550386f5<br/><br/> handy.h: Collapse some macros<br/> Karl Williamson 1 file changed, 6 insertions(+), 11 deletions(-)<br/> https://github.com/Perl/perl5/commit/cb86f083e3aeda69<br/><br/> handy.h: Move some macro defns around<br/> Karl Williamson 1 file changed, 45 insertions(+), 45 deletions(-<br/> https://github.com/Perl/perl5/commit/41dc6644e302365c<br/><br/> handy.h: Collapse two sets of macros<br/> Karl Williamson 1 file changed, 15 insertions(+), 29 deletions(-<br/> https://github.com/Perl/perl5/commit/532d799b08517a3c<br/><br/> No locales =&gt; don&#39;t use isspace(), toLower() etc.<br/> Karl Williamson 1 file changed, 16 insertions(+), 16 deletions(-<br/> https://github.com/Perl/perl5/commit/bdf77e6fc4f25079<br/><br/> handy.h: #define one macro in terms of another<br/> Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/b5cbd56bd3d30f6c<br/><br/> handy.h: Rmv unnecessary parameter to internal macros<br/> Karl Williamson 1 file changed, 9 insertions(+), 9 deletions(-)<br/> https://github.com/Perl/perl5/commit/018f1acf08d871e5<br/><br/> handy.h: Refactor some internal macros<br/> Karl Williamson 1 file changed, 12 insertions(+), 15 deletions(-<br/> https://github.com/Perl/perl5/commit/c1b45cf49c0318be<br/><br/> handy.h: Rmv internal macro<br/> Karl Williamson 1 file changed, 2 insertions(+), 5 deletions(-)<br/> https://github.com/Perl/perl5/commit/c2d6cc50a15cd33c<br/><br/> Change handy.h macro names to be C standard conformant<br/> Karl Williamson 13 files changed, 1062 insertions(+), 1063 delet<br/> https://github.com/Perl/perl5/commit/c8c95926798ca202<br/><br/> handy.h: Don&#39;t use char class if no LC_CTYPE<br/> Karl Williamson 1 file changed, 1 insertion(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/2a8fe80fa51994a2<br/><br/> handy.h: White-space, comment only<br/> Karl Williamson 1 file changed, 87 insertions(+), 77 deletions(-<br/> https://github.com/Perl/perl5/commit/cc4857bdc3bc95d2<br/><br/> handy.h: Add some branch predictions<br/> Karl Williamson 1 file changed, 6 insertions(+), 6 deletions(-)<br/> https://github.com/Perl/perl5/commit/58a9dc82c123dad8<br/><br/> handy.h: Refactor some #ifdef&#39;s for commonality<br/> Karl Williamson 1 file changed, 18 insertions(+), 23 deletions(-<br/> https://github.com/Perl/perl5/commit/6a7dfa479746628e<br/><br/> handy.h: Remove only 2 calls to an internal macro<br/> Karl Williamson 1 file changed, 2 insertions(+), 9 deletions(-)<br/> https://github.com/Perl/perl5/commit/474e5216f55205ac<br/><br/> Change handy.h macro names to be C standard conformant<br/> Karl Williamson 5 files changed, 203 insertions(+), 203 deletion<br/> https://github.com/Perl/perl5/commit/63c1ecb73ec22b08<br/><br/> locale.c: Replace most #ifdef DEBUGGING lines<br/> Karl Williamson 1 file changed, 93 insertions(+), 253 deletions(<br/> https://github.com/Perl/perl5/commit/5c397328e3bd4a28<br/><br/> DEBUG_L now also looks at environment variable<br/> Karl Williamson 2 files changed, 25 insertions(+), 13 deletions(<br/> https://github.com/Perl/perl5/commit/64dba89a2b8984b1<br/><br/> XXX locale_threads<br/> Karl Williamson 1 file changed, 590 insertions(+), 52 deletions(<br/> https://github.com/Perl/perl5/commit/2de434a110335eb9<br/><br/> locale.c: Win32: Don&#39;t check folds validity<br/> Karl Williamson 1 file changed, 11 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/89dca447af1d1e9c<br/><br/> XXX craig Unixish.h, doshish.h: Reorder terminations; simplify<br/> Karl Williamson 2 files changed, 23 insertions(+), 22 deletions(<br/> https://github.com/Perl/perl5/commit/fcd11417cfa5cd84<br/><br/>Deleted branch smoke-me/khw-env<br/><br/>Martian commit f5055c23cc4b6d989c2acb2da8af16cdbc46aa19<br/>2 commits. 2 unique authors. 2 unique committers.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/f5055c23cc4b6d98<br/><br/> Merge 1fd9fa1cd27cade04086077e06e23c5175d30510 into d6b338e16ce631123b5bae0e<br/> xenu 2 parents<br/> https://github.com/Perl/perl5/commit/f5055c23cc4b6d98<br/><br/> win32.c: make reading UTF-8 characters from the console possible<br/> Tomasz Konojacki 1 file changed, 125 insertions(+), 1 deletion(-)<br/> https://github.com/Perl/perl5/commit/1fd9fa1cd27cade0<br/><br/>Martian commit 03f7c383f74bd04ee4a5137162a21098777648b6<br/>2 commits. 1 unique author. 2 unique committers.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/03f7c383f74bd04e<br/><br/> Merge 0ea2594ed8db2b45be8eaaad73019395f7d765ab into d6b338e16ce631123b5bae0e<br/> Felipe Gasper 2 parents<br/> https://github.com/Perl/perl5/commit/03f7c383f74bd04e<br/><br/> Docs: Emphasize SvPVbyte and SvPVutf8 over SvPV. This updates<br/> Felipe Gasper 5 files changed, 154 insertions(+), 29 deletions<br/> https://github.com/Perl/perl5/commit/0ea2594ed8db2b45<br/><br/>Martian commit f652b4039bb6cc76d2992b3f6b8af250fdf537cc<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/f652b4039bb6cc76<br/><br/> Merge 0105cf98dabb886a72baa5375ea787ac0f2b4537 into d6b338e16ce631123b5bae0e<br/> Karl Williamson 2 parents<br/> https://github.com/Perl/perl5/commit/f652b4039bb6cc76<br/><br/>Martian commit f44bfdfd3d28c372fa1066711d24a469bc181da5<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/f44bfdfd3d28c372<br/><br/> Merge fd0cd1b62cf35ecfaa9e47c54c5a0960ccb08306 into d6b338e16ce631123b5bae0e<br/> Leon Timmermans 2 parents<br/> https://github.com/Perl/perl5/commit/f44bfdfd3d28c372<br/><br/>Martian commit 7977ad6658c10c5d57cb435fdd02d3a8f63c0ebb<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/7977ad6658c10c5d<br/><br/> Merge c6fcd87f74e0ef4177835b6fb3aec47f97fe4ed9 into d6b338e16ce631123b5bae0e<br/> Tony Cook 2 parents<br/> https://github.com/Perl/perl5/commit/7977ad6658c10c5d<br/><br/>Martian commit b511d14a5438ec34f301c16f355d08014800c67a<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/b511d14a5438ec34<br/><br/> Merge f0312d1990b1d7afa9f138c4a4ca390c71775f4e into d6b338e16ce631123b5bae0e<br/> Max Maischein 2 parents<br/> https://github.com/Perl/perl5/commit/b511d14a5438ec34<br/><br/>Martian commit 03be311dd7b290e7085295122e4ddcaf66f6ddd0<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/03be311dd7b290e7<br/><br/> Merge 4f33871e476d22c53497f8752b4846aecb7d661a into d6b338e16ce631123b5bae0e<br/> Karl Williamson 2 parents<br/> https://github.com/Perl/perl5/commit/03be311dd7b290e7<br/><br/>Martian commit 685ef637a605d97969c3de10f00ed96b265bc770<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/685ef637a605d979<br/><br/> Merge b883c1499282ee1bef9809a1897a8cb9a033ac05 into d6b338e16ce631123b5bae0e<br/> Karl Williamson 2 parents<br/> https://github.com/Perl/perl5/commit/685ef637a605d979<br/><br/>Martian commit 4b005bf4a03218ed9c9a5855f1f1ea4145c5aabb<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/4b005bf4a03218ed<br/><br/> Merge e23baf131a48342bff7a00f06b2f84abbf139847 into d6b338e16ce631123b5bae0e<br/> Karen Etheridge 2 parents<br/> https://github.com/Perl/perl5/commit/4b005bf4a03218ed<br/><br/>Martian commit 86a72459fc98327a85a7cec49118b819b8557c89<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/86a72459fc98327a<br/><br/> Merge 8739008b5a39ccb9ba76c738796982b0b15d3b14 into d6b338e16ce631123b5bae0e<br/> Tony Cook 2 parents<br/> https://github.com/Perl/perl5/commit/86a72459fc98327a<br/><br/>Martian commit b922e82389ea734c67f2f523df04b05549e7f49e<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/b922e82389ea734c<br/><br/> Merge 76365c82b2d4d128babe60028d385cb406bd1de1 into d6b338e16ce631123b5bae0e<br/> Tony Cook 2 parents<br/> https://github.com/Perl/perl5/commit/b922e82389ea734c<br/><br/>Martian commit c3e4ecd6fd5a630174b16ebb65855bd0f30149f0<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/c3e4ecd6fd5a6301<br/><br/> Merge 9484cdf48215de91203fa60fb27e9a0546d00c7d into d6b338e16ce631123b5bae0e<br/> Leon Timmermans 2 parents<br/> https://github.com/Perl/perl5/commit/c3e4ecd6fd5a6301<br/><br/>Martian commit 1c1315a40f6b53813514aa169a72650cb7624b52<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/1c1315a40f6b5381<br/><br/> Merge 6786f7b53ce2b445d286064dcafffe102bf5f50c into d6b338e16ce631123b5bae0e<br/> Felipe Gasper 2 parents<br/> https://github.com/Perl/perl5/commit/1c1315a40f6b5381<br/><br/>Martian commit 3f6968dd0d3c2edef900742c8a780fbdc3c50373<br/>4 commits. 1 unique author. 2 unique committers.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/3f6968dd0d3c2ede<br/><br/> Merge 528fb9148e51d0d529c70856dfba6d1d8540fc99 into d6b338e16ce631123b5bae0e<br/> Richard Leach 2 parents<br/> https://github.com/Perl/perl5/commit/3f6968dd0d3c2ede<br/><br/> Perl_pad_new: directly allocate SV* array, remove av_store() calls<br/> Richard Leach 1 file changed, 9 insertions(+), 2 deletions(-)<br/> https://github.com/Perl/perl5/commit/528fb9148e51d0d5<br/><br/> Perl_pad_push: directly allocate SV* array, remove av_store() calls<br/> Richard Leach 1 file changed, 6 insertions(+), 2 deletions(-)<br/> https://github.com/Perl/perl5/commit/8f9a628465043b15<br/><br/> Perl_pad_push: assign the SV to store in sv, use single av_store()<br/> Richard Leach 1 file changed, 5 insertions(+), 6 deletions(-)<br/> https://github.com/Perl/perl5/commit/e178aed7276b8622<br/><br/>Martian commit fa0865fc8422096d920566450a2e6b264f829401<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/fa0865fc8422096d<br/><br/> Merge 2238db2ab3b9022dc11041f766cf6aa31216eaf4 into d6b338e16ce631123b5bae0e<br/> Max Maischein 2 parents<br/> https://github.com/Perl/perl5/commit/fa0865fc8422096d<br/><br/>Martian commit bef8d65aab5295c4cfa9dfd1ac2e6a24ec0aa1fa<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/bef8d65aab5295c4<br/><br/> Merge dbcbd8c9b3f82fb2b3da1d3acd6fb87bad7f35c4 into d6b338e16ce631123b5bae0e<br/> Max Maischein 2 parents<br/> https://github.com/Perl/perl5/commit/bef8d65aab5295c4<br/><br/>Martian commit 5ed31476ff5584c6e9917b42eded6d766b725cb9<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/5ed31476ff5584c6<br/><br/> Merge 7ff86f94ca59351cc4f2b3dfc66e25efcae978d8 into d6b338e16ce631123b5bae0e<br/> Todd Rinaldo 2 parents<br/> https://github.com/Perl/perl5/commit/5ed31476ff5584c6<br/><br/>Martian commit 6cf8b311bcc7dc2dc6b4f1687e73734be8dc9f6b<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/6cf8b311bcc7dc2d<br/><br/> Merge 511f1d6d91af0f1d141953aa6d50e0361e6a083e into d6b338e16ce631123b5bae0e<br/> Tony Cook 2 parents<br/> https://github.com/Perl/perl5/commit/6cf8b311bcc7dc2d<br/><br/>Martian commit e76e214c48175b01d34a32caf8fe4c64b3a30f84<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/e76e214c48175b01<br/><br/> Merge 452512323451c0aadc55ec9b432b26613ca708d7 into d6b338e16ce631123b5bae0e<br/> brian d foy 2 parents<br/> https://github.com/Perl/perl5/commit/e76e214c48175b01<br/><br/>Martian commit 2442f11d1a691e2b9fc1bf36423b6eeb57129735<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/2442f11d1a691e2b<br/><br/> Merge 3ed68dae7121cf1b8dc35d3f708dac253f32edf5 into d6b338e16ce631123b5bae0e<br/> Leon Timmermans 2 parents<br/> https://github.com/Perl/perl5/commit/2442f11d1a691e2b<br/><br/>Martian commit 2b348c8e876d7daedc1352f6b6e18a2fa12022ac<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/2b348c8e876d7dae<br/><br/> Merge f35aa1d466a9ac922d111ad7919e5d2c5d538cf9 into d6b338e16ce631123b5bae0e<br/> &ETH;&#156;&ETH;&cedil;&Ntilde;&#133;&ETH;&deg;&ETH;&cedil;&ETH;&raquo; &ETH;&#154;&ETH;&frac34;&ETH;&middot;&ETH;&deg;&Ntilde;&#135;&ETH;&ordm;&ETH;&frac34;&ETH;&sup2; 2 parents<br/> https://github.com/Perl/perl5/commit/2b348c8e876d7dae<br/><br/>Martian commit 97ac81e50fb44da58a32d655549ca413ef189f97<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/97ac81e50fb44da5<br/><br/> Merge 13858c2e061870d963856ddce3943e9703f50638 into d6b338e16ce631123b5bae0e<br/> xenu 2 parents<br/> https://github.com/Perl/perl5/commit/97ac81e50fb44da5<br/><br/>Martian commit 8e601bb481e7e6f18f88e6a7b941c4bc5848d153<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/8e601bb481e7e6f1<br/><br/> Merge c2d3c9b4e7d8ddbdb932ccea1c1e38cd23e79e21 into d6b338e16ce631123b5bae0e<br/> Marc Reisner 2 parents<br/> https://github.com/Perl/perl5/commit/8e601bb481e7e6f1<br/><br/>Martian commit e581dfe4892a83242650219cc5959f827b657b6f<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/e581dfe4892a8324<br/><br/> Merge 372b43d8679f1dfaf8f4198b4d24c6f175b75a79 into d6b338e16ce631123b5bae0e<br/> xenu 2 parents<br/> https://github.com/Perl/perl5/commit/e581dfe4892a8324<br/><br/>Martian commit 7dd67bc77492ff011e9c701acc58a4e2e17bb0b7<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/7dd67bc77492ff01<br/><br/> Merge 1b48c014535c153219027ff01e4a0bad1d1bb9c9 into d6b338e16ce631123b5bae0e<br/> TAKAI Kousuke 2 parents<br/> https://github.com/Perl/perl5/commit/7dd67bc77492ff01<br/><br/>Martian commit deaf52c7bb6e8d6bfaf6458248857360745e23ea<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/deaf52c7bb6e8d6b<br/><br/> Merge 7683e280de4f493687397ccafc0eee4315b29321 into d6b338e16ce631123b5bae0e<br/> Max Maischein 2 parents<br/> https://github.com/Perl/perl5/commit/deaf52c7bb6e8d6b<br/><br/>Martian commit b82c624630afd00415687c5d1a0599abb5613780<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/b82c624630afd004<br/><br/> Merge e7e9b97fe983e864785d13dbfecf8fd5990403aa into d6b338e16ce631123b5bae0e<br/> Scott Baker 2 parents<br/> https://github.com/Perl/perl5/commit/b82c624630afd004<br/><br/>Martian commit 13690959b33cd39f6b9498786acab2c188808d7b<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/13690959b33cd39f<br/><br/> Merge 79eaec491c87571fa5006b5af2c71cf1067f5b8f into d6b338e16ce631123b5bae0e<br/> Scott Baker 2 parents<br/> https://github.com/Perl/perl5/commit/13690959b33cd39f<br/><br/>Martian commit 406e77dbfbbc9a6cc1603d9ed5631d0f2af89ab3<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/406e77dbfbbc9a6c<br/><br/> Merge dc44b362e1e298e327be398f06def916f8546ac2 into d6b338e16ce631123b5bae0e<br/> Richard Leach 2 parents<br/> https://github.com/Perl/perl5/commit/406e77dbfbbc9a6c<br/><br/>Martian commit 3743b1fd647985c37dae30b92d28c6237df096c9<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/3743b1fd647985c3<br/><br/> Merge a74e03609a90cdaec4c40914e17a4fd1dbcfbbf5 into d6b338e16ce631123b5bae0e<br/> &acirc;&#132;&#149;icolas &acirc;&#132;&#157; 2 parents<br/> https://github.com/Perl/perl5/commit/3743b1fd647985c3<br/><br/>Martian commit 1f5148b5e64b505c877f66477d681047918b4e4f<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/1f5148b5e64b505c<br/><br/> Merge 6d60a8e144f2b1539005f96e83de69a4132ad890 into d6b338e16ce631123b5bae0e<br/> Sawyer X 2 parents<br/> https://github.com/Perl/perl5/commit/1f5148b5e64b505c<br/><br/>Martian commit 3c92ab1b03edc49eea7717737d1304a40aa5c9df<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/3c92ab1b03edc49e<br/><br/> Merge 51d41593234a666d435ec95bb40ebbfc419ac222 into d6b338e16ce631123b5bae0e<br/> Karl Williamson 2 parents<br/> https://github.com/Perl/perl5/commit/3c92ab1b03edc49e<br/><br/>Martian commit 18c952da38381a6106ec2dfaab7f1dab0bdb2fdb<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/18c952da38381a61<br/><br/> Merge a5d767b2a27c7a4376fc21ed73cff6a91274d3fd into d6b338e16ce631123b5bae0e<br/> Karl Williamson 2 parents<br/> https://github.com/Perl/perl5/commit/18c952da38381a61<br/><br/>Martian commit bf03e9ca89f278d2e06cacc7fbbd800140c6b516<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/bf03e9ca89f278d2<br/><br/> Merge 77878eb22a9a9784647af0a234adc9f1358c0d46 into d6b338e16ce631123b5bae0e<br/> Max Maischein 2 parents<br/> https://github.com/Perl/perl5/commit/bf03e9ca89f278d2<br/><br/>Martian commit 7e47399575a6915b1b8e9dfa97765cf330ec9231<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/7e47399575a6915b<br/><br/> Merge 06c305c565bda4331eac3385935a7dbdb258a626 into d6b338e16ce631123b5bae0e<br/> Richard Leach 2 parents<br/> https://github.com/Perl/perl5/commit/7e47399575a6915b<br/><br/>Martian commit 55511f6a85f823e4b023935288284e07f7681ec3<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/55511f6a85f823e4<br/><br/> Merge d2bb3a0c6f78eb0c88c4a2ece60d2e8e3bfbaf76 into d6b338e16ce631123b5bae0e<br/> Leon Timmermans 2 parents<br/> https://github.com/Perl/perl5/commit/55511f6a85f823e4<br/><br/>Martian commit fe541c5a02a2a8a378e1a5a1987d2231b77b8260<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/fe541c5a02a2a8a3<br/><br/> Merge 6ce11f2e46354b78114eec64a433f0591a72fb3c into d6b338e16ce631123b5bae0e<br/> H.Merijn Brand 2 parents<br/> https://github.com/Perl/perl5/commit/fe541c5a02a2a8a3<br/><br/>Martian commit a879d734387548d9bfbe6ce03467a82a470aae0f<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/a879d734387548d9<br/><br/> Merge f2e2c9c3d3d737bbe4bc8a84bc5e9faa2072f446 into d6b338e16ce631123b5bae0e<br/> Yves Orton 2 parents<br/> https://github.com/Perl/perl5/commit/a879d734387548d9<br/><br/>Martian commit 0cbfd00f89d5a421ff1aa1d0c3f0271750381554<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/0cbfd00f89d5a421<br/><br/> Merge 9d6bb0e8ff7c395532bd508cfeb92454150caedc into d6b338e16ce631123b5bae0e<br/> TAKAI Kousuke 2 parents<br/> https://github.com/Perl/perl5/commit/0cbfd00f89d5a421<br/><br/>Martian commit 1891172c19a301eb5a8a0f86bd87263039a3c2ab<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/1891172c19a301eb<br/><br/> Merge aa09c967d54cfba8bbce4617f8347e5241dd322c into d6b338e16ce631123b5bae0e<br/> TAKAI Kousuke 2 parents<br/> https://github.com/Perl/perl5/commit/1891172c19a301eb<br/><br/>Martian commit dff927457f5b4bb4cb24287dc88abe5142123569<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/dff927457f5b4bb4<br/><br/> Merge e582ed423c9152383498834d5f9b3fcbf22ba604 into d6b338e16ce631123b5bae0e<br/> E. Choroba 2 parents<br/> https://github.com/Perl/perl5/commit/dff927457f5b4bb4<br/><br/>Martian commit 1f87b97169c19e6f414503ae243ebfeacd3eeb41<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/1f87b97169c19e6f<br/><br/> Merge 10083f11dbb5a4a9335d1877f7cb5c02811882dd into d6b338e16ce631123b5bae0e<br/> Tony Cook 2 parents<br/> https://github.com/Perl/perl5/commit/1f87b97169c19e6f<br/><br/>Martian commit 0a33a3eec11376ed1d36aa360901a028fd85ef1a<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/0a33a3eec11376ed<br/><br/> Merge 8c7ed718e27099ba2cdc32c959ff8199ae7d966a into d6b338e16ce631123b5bae0e<br/> H.Merijn Brand 2 parents<br/> https://github.com/Perl/perl5/commit/0a33a3eec11376ed<br/><br/>Martian commit a84c686d0c4a785cc7b2222effff98cbf57f9252<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/a84c686d0c4a785c<br/><br/> Merge c67a1850d2b751065133fa1a406c24a393c00366 into d6b338e16ce631123b5bae0e<br/> John Lightsey 2 parents<br/> https://github.com/Perl/perl5/commit/a84c686d0c4a785c<br/><br/>Martian commit d8a7824cba2715697b1310cebda40ac4c9754cba<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/d8a7824cba271569<br/><br/> Merge 848ca18082cab10654fb9de5355bfb059d5ab6cd into d6b338e16ce631123b5bae0e<br/> jpalao 2 parents<br/> https://github.com/Perl/perl5/commit/d8a7824cba271569<br/><br/>Martian commit 0d1863506f1ff94b91ba5ab1f59f0dc0a9b0a8a0<br/>1 commit. 1 unique author. 1 unique committer.<br/>Thanks, applied: GitHub (1)<br/>Snapshot: http://github.com/Perl/perl5/tarball/0d1863506f1ff94b<br/><br/> Merge ea76afd4f1fc3b2abfe36e9b5cf396d49a9b3500 into d6b338e16ce631123b5bae0e<br/> Tony Cook 2 parents<br/> https://github.com/Perl/perl5/commit/0d1863506f1ff94b<br/><br/>Martian commit 172902d7f08c2b5458247f57cbb9ebee9db440f5<br/>1 commit. 1 unique author. 1 unique committer.<br/><br/>Snapshot: http://github.com/Perl/perl5/tarball/172902d7f08c2b54<br/><br/> Correct documentation of indent Style 2<br/> James E Keenan 1 file changed, 10 insertions(+), 11 deletions(-<br/> https://github.com/Perl/perl5/commit/172902d7f08c2b54<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259781.html Sat, 10 Apr 2021 03:05:27 +0000 Re: CPAN release of ExtUtils-ParseXS by Ben Bullock On Sat, 10 Apr 2021 at 02:46, James E Keenan &lt;jkeenan@pobox.com&gt; wrote:<br/><br/>&gt; &gt; Could you check it again?<br/>&gt;<br/>&gt; That looks a lot better.<br/><br/>Thank you for checking it.<br/><br/>&gt; Sawyer / Rik: could you take this from here?<br/><br/>The information I was given is that various people will be asked to<br/>check the distribution before anything else is decided.<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259780.html Fri, 09 Apr 2021 23:47:53 +0000 by Leon Timmermans On Fri, Apr 9, 2021 at 9:40 PM David Christensen<br/>&lt;dpchrist@holgerdanske.com&gt; wrote:<br/>&gt; Regarding Perl interpreter threads:<br/>&gt;<br/>&gt; 1. Are interpreter threads still considered a mistake?<br/><br/>I think that they&#39;re the best threads we can offer on the<br/>implementation that we have.<br/><br/>I do think that using threads.pm is almost always a mistake. This is<br/>mostly because using threads::shared is almost always a mistake, and<br/>it&#39;s rare to see the former being used without the latter.<br/><br/>&gt; 2. Are interpreter threads standing in the way of any significant<br/>&gt; improvement(s) in the Perl core? If so, what improvement(s)?<br/><br/>Not really AFAIK, though they do complicate some things.<br/><br/>&gt; 3. Are there current plans to remove interpreter threads from Perl?<br/>&gt; When? What Perl version?<br/><br/>Not that I know of.<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259779.html Fri, 09 Apr 2021 22:42:30 +0000 by Dan Book On Fri, Apr 9, 2021 at 4:18 PM B. Estrade &lt;brett@cpanel.net&gt; wrote:<br/><br/>&gt;<br/>&gt;<br/>&gt; On 4/9/21 2:30 PM, David Christensen wrote:<br/>&gt; &gt; https://en.wikipedia.org/wiki/Perl_5_version_history<br/>&gt; &gt;<br/>&gt; &gt; Perl 5.8.0:<br/>&gt; &gt;<br/>&gt; &gt; * Introduction of interpreter threads<br/>&gt; &gt;<br/>&gt; &gt; * 5.005 threads are deprecated.<br/>&gt; &gt;<br/>&gt; &gt;<br/>&gt; &gt; https://github.com/Perl/perl5/issues/14691<br/>&gt; &gt;<br/>&gt; &gt;<br/>&gt; &gt; @ikegami<br/>&gt; &gt;<br/>&gt; &gt; threads.pm says:<br/>&gt; &gt;<br/>&gt; &gt; The use of interpreter-based threads in perl is officially<br/>&gt; &gt; discouraged.<br/>&gt; &gt;<br/>&gt; &gt;<br/>&gt; &gt; @rcaputo<br/>&gt; &gt;<br/>&gt; &gt; The discouragement was added on Mar 2, 2014 after an intense<br/>&gt; &gt; deliberation on perl5-porters:<br/>&gt; &gt;<br/>&gt; &gt;<br/>&gt; &gt; @ikegami<br/>&gt; &gt; - *discouraged*<br/>&gt; &gt;<br/>&gt; &gt; From time to time, we may mark language constructs and features<br/>&gt; &gt; which we consider to have been mistakes as *discouraged*.<br/>&gt; &gt; Discouraged features aren&#39;t currently candidates for removal,<br/>&gt; &gt; but we may later deprecate them if they&#39;re found to stand in the<br/>&gt; &gt; way of a significant improvement to the Perl core.<br/>&gt; &gt;<br/>&gt; &gt;<br/>&gt; &gt; Konovalov, Vadim wrote on April 8, 2021 08:42<br/>&gt; &gt;<br/>&gt; &gt; Perl history on threading (PERL5005THREADS and then ITHREADS where<br/>&gt; &gt; 1st was deprecated and removed while 2nd was recently deprecated)<br/>&gt; &gt;<br/>&gt; &gt;<br/>&gt; &gt; Regarding Perl interpreter threads:<br/>&gt; &gt;<br/>&gt; &gt; 1. Are interpreter threads still considered a mistake?<br/>&gt; &gt;<br/>&gt; &gt; 2. Are interpreter threads standing in the way of any significant<br/>&gt; &gt; improvement(s) in the Perl core? If so, what improvement(s)?<br/>&gt; &gt;<br/>&gt; &gt; 3. Are there current plans to remove interpreter threads from Perl?<br/>&gt; &gt; When? What Perl version?<br/>&gt;<br/>&gt; I am certainly not trying to &quot;pile on&quot;, but I do have an interesting and<br/>&gt; potentially informative addition to this summary that some are not aware<br/>&gt; exists:<br/>&gt;<br/>&gt; https://metacpan.org/pod/Coro#DESCRIPTION<br/>&gt; https://metacpan.org/pod/Coro#WINDOWS-PROCESS-EMULATION<br/>&gt;<br/>&gt; I share this knowing only incidentally of past negativeness; but I feel<br/>&gt; like this is relevant nonetheless. Not at all to promote Coro; just to<br/>&gt; provide information.<br/>&gt;<br/><br/>Marc puts a lot of opinions in his module documentation that should be<br/>taken with large grains of salt in every instance. Here his spiel about<br/>ithreads belies that Coro is in fact not &quot;real threads&quot; - it is an<br/>implementation of &quot;green threads&quot; like Python&#39;s, and requires<br/>Coro::Multicore to operate in parallel.<br/><br/>-Dan<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259778.html Fri, 09 Apr 2021 20:34:42 +0000 by Dan Book On Fri, Apr 9, 2021 at 3:40 PM David Christensen &lt;dpchrist@holgerdanske.com&gt;<br/>wrote:<br/><br/>&gt; Regarding Perl interpreter threads:<br/>&gt;<br/>&gt; 1. Are interpreter threads still considered a mistake?<br/>&gt;<br/><br/>They are currently the implementation of fork() on Windows so are required.<br/>I can&#39;t speak to whether anyone would classify it as a mistake. Personally<br/>I think they are nonideal for most use cases.<br/><br/><br/>&gt; 2. Are interpreter threads standing in the way of any significant<br/>&gt; improvement(s) in the Perl core? If so, what improvement(s)?<br/>&gt;<br/><br/>It&#39;s more difficult to implement things in a thread-safe manner, but this<br/>isn&#39;t specific to the specific implementation of threads.<br/><br/><br/>&gt; 3. Are there current plans to remove interpreter threads from Perl?<br/>&gt; When? What Perl version?<br/><br/><br/>No.<br/><br/>-Dan<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259777.html Fri, 09 Apr 2021 20:27:41 +0000 by B. Estrade <br/><br/>On 4/9/21 2:30 PM, David Christensen wrote:<br/>&gt; https://en.wikipedia.org/wiki/Perl_5_version_history<br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; Perl 5.8.0:<br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; * Introduction of interpreter threads<br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; * 5.005 threads are deprecated.<br/>&gt; <br/>&gt; <br/>&gt; https://github.com/Perl/perl5/issues/14691<br/>&gt; <br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; @ikegami<br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; threads.pm says&#x200B;:<br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; The use of interpreter-based threads in perl is officially<br/>&gt; &nbsp;&nbsp;&nbsp; discouraged.<br/>&gt; <br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; @rcaputo<br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; The discouragement was added on Mar 2, 2014 after an intense<br/>&gt; &nbsp;&nbsp;&nbsp; deliberation on perl5-porters&#x200B;:<br/>&gt; <br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; @ikegami<br/>&gt; &nbsp;&nbsp;&nbsp; - *discouraged*<br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; From time to time, we may mark language constructs and features<br/>&gt; &nbsp;&nbsp;&nbsp; which we consider to have been mistakes as *discouraged*.<br/>&gt; &nbsp;&nbsp;&nbsp; Discouraged features aren&#39;t currently candidates for removal,<br/>&gt; &nbsp;&nbsp;&nbsp; but we may later deprecate them if they&#39;re found to stand in the<br/>&gt; &nbsp;&nbsp;&nbsp; way of a significant improvement to the Perl core.<br/>&gt; <br/>&gt; <br/>&gt; Konovalov, Vadim wrote on April 8, 2021 08:42<br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; Perl history on threading (PERL5005THREADS and then ITHREADS where<br/>&gt; &nbsp;&nbsp;&nbsp; 1st was deprecated and removed while 2nd was recently deprecated)<br/>&gt; <br/>&gt; <br/>&gt; Regarding Perl interpreter threads:<br/>&gt; <br/>&gt; 1.&nbsp; Are interpreter threads still considered a mistake?<br/>&gt; <br/>&gt; 2.&nbsp; Are interpreter threads standing in the way of any significant <br/>&gt; improvement(s) in the Perl core?&nbsp; If so, what improvement(s)?<br/>&gt; <br/>&gt; 3.&nbsp; Are there current plans to remove interpreter threads from Perl? <br/>&gt; When?&nbsp; What Perl version?<br/><br/>I am certainly not trying to &quot;pile on&quot;, but I do have an interesting and <br/>potentially informative addition to this summary that some are not aware <br/>exists:<br/><br/>https://metacpan.org/pod/Coro#DESCRIPTION<br/>https://metacpan.org/pod/Coro#WINDOWS-PROCESS-EMULATION<br/><br/>I share this knowing only incidentally of past negativeness; but I feel <br/>like this is relevant nonetheless. Not at all to promote Coro; just to <br/>provide information.<br/><br/>Brett<br/><br/>&gt; <br/>&gt; <br/>&gt; David<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259776.html Fri, 09 Apr 2021 20:18:40 +0000 by David Christensen https://en.wikipedia.org/wiki/Perl_5_version_history<br/><br/> Perl 5.8.0:<br/><br/> * Introduction of interpreter threads<br/><br/> * 5.005 threads are deprecated.<br/><br/><br/>https://github.com/Perl/perl5/issues/14691<br/><br/><br/> @ikegami<br/><br/> threads.pm says&#x200B;:<br/><br/> The use of interpreter-based threads in perl is officially<br/> discouraged.<br/><br/><br/> @rcaputo<br/><br/> The discouragement was added on Mar 2, 2014 after an intense<br/> deliberation on perl5-porters&#x200B;:<br/><br/><br/> @ikegami<br/> - *discouraged*<br/><br/> From time to time, we may mark language constructs and features<br/> which we consider to have been mistakes as *discouraged*.<br/> Discouraged features aren&#39;t currently candidates for removal,<br/> but we may later deprecate them if they&#39;re found to stand in the<br/> way of a significant improvement to the Perl core.<br/><br/><br/>Konovalov, Vadim wrote on April 8, 2021 08:42<br/><br/> Perl history on threading (PERL5005THREADS and then ITHREADS where<br/> 1st was deprecated and removed while 2nd was recently deprecated)<br/><br/><br/>Regarding Perl interpreter threads:<br/><br/>1. Are interpreter threads still considered a mistake?<br/><br/>2. Are interpreter threads standing in the way of any significant <br/>improvement(s) in the Perl core? If so, what improvement(s)?<br/><br/>3. Are there current plans to remove interpreter threads from Perl? <br/>When? What Perl version?<br/><br/><br/>David<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259775.html Fri, 09 Apr 2021 19:40:43 +0000 Re: CPAN release of ExtUtils-ParseXS by James E Keenan On 4/8/21 5:22 PM, Ben Bullock wrote:<br/>&gt; On Thu, 8 Apr 2021 at 22:47, James E Keenan &lt;jkeenan@pobox.com&gt; wrote:<br/>&gt; <br/>&gt;&gt; Ben, I&#39;m concerned that in your tarball you are not completely capturing<br/>&gt;&gt; the state of ExtUtils-ParseXS as it currently appears in blead. As a<br/>&gt;&gt; consequence, if you were to release what&#39;s in your tarball to CPAN, what<br/>&gt;&gt; is stated to be version 3.43 on CPAN would be subtly different from what<br/>&gt;&gt; will presumably be version 3.43 in dist/ExtUtils-ParseXS when we release<br/>&gt;&gt; perl-5.34.0 next month.<br/>&gt; <br/>&gt; I personally am not currently due to release anything to CPAN, I&#39;m<br/>&gt; just doing the work on preparing the files for release. The current<br/>&gt; job is to review the changes and check the files are all OK.<br/>&gt; <br/>&gt;&gt; Now, if (a) I download and unpack your tarball, then (b) do a &quot;git<br/>&gt;&gt; checkout 99155265&quot;, and then (c) diff blead against your tarball, I come<br/>&gt;&gt; up with the diff attached (eupp.99155265b6.vs.proposed.diff). Much of<br/>&gt;&gt; the diff is housekeeping, but I&#39;m concerned that Ed J&#39;s changes don&#39;t<br/>&gt;&gt; make the diff. Also missing are changes to<br/>&gt;&gt; dist/ExtUtils-ParseXS/t/XSTest.xs and dist/ExtUtils-ParseXS/t/XSUsage.xs<br/>&gt;&gt; that were committed in Nov 2017 in commit a8c15670317. The most<br/>&gt;&gt; relevant differences I am attaching as &quot;relevant.diff&quot;.<br/>&gt; <br/>&gt; We lost some changes because I didn&#39;t copy /t/ properly. Originally I<br/>&gt; copied all the files under dist/ExtUtils-ParseXS, then found that the<br/>&gt; perldoc files in lib weren&#39;t part of the dual-life distribution by<br/>&gt; Stefan Mueller on CPAN, so I just copied lib, to omit the perldoc<br/>&gt; files, and forgot to copy /t/. I&#39;ve now copied this and made a new tag<br/>&gt; release here:<br/>&gt; <br/>&gt; https://github.com/benkasminbullock/extutils-parsexs/releases/tag/3.43_02<br/>&gt; <br/>&gt; Could you check it again?<br/><br/>That looks a lot better. Sawyer / Rik: could you take this from here?<br/><br/>Thank you very much.<br/>Jim Keenan<br/><br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259774.html Fri, 09 Apr 2021 17:47:07 +0000 by B. Estrade Thank you for your continued thoughts, time, and attention. If all we do <br/>is starting thinking about it, which I think these threads have <br/>accomplished, then it&#39;s progress. I remain confident someone out there <br/>will have an epiphany. All I can offer is encouragement, continued <br/>thought, and those examples I posted showing how I can imaging what I am <br/>thinking about from a Perl programmer&#39;s perspective - taking into <br/>account only the external developer experience and what I&#39;ve <br/>internalized idiomatically over the years.<br/><br/>I&#39;m happy to continue to mention it, but I know there are other pressing <br/>matters. I will just sum it up by reiterating what I think the most <br/>important points are, for me:<br/><br/>* Perl&#39;s future relevance must be, in large part, driven through <br/>interesting and hard application areas (the SMP thing came from only one <br/>example, but that sort of took on a life of its own)<br/><br/>* SMP is a crucial capability, even if not threads. OpenMP is not <br/>general threading; it&#39;s a very limited model. Perl just needs to provide <br/>a very small subset; what that looks like versus what is possible, I can <br/>not assert. We should always be keeping it mind. Our collective <br/>unconscious will reveal what that looks like when it is the right time. <br/>I have faith in that.<br/><br/>* Perl has nothing to prove to language weenies; it has everything to <br/>prove to it&#39;s loyal following - practical people doing things they deem <br/>to be serious, in a fun and productive ways.<br/><br/>Thank you all, again, for everything. Especially the discussions and <br/>considerations this topic has been afforded.<br/><br/>Cheers,<br/>Brett<br/><br/>On 4/9/21 8:31 AM, Nicholas Clark wrote:<br/>&gt; On Wed, Apr 07, 2021 at 08:49:31PM -0500, B. Estrade wrote:<br/>&gt;&gt; FWIW, I can accept that fundamentally this violates any number of basic<br/>&gt;&gt; assumptions in the perl runtime. I know it&#39;s interpreted, dynamic, etc. I<br/>&gt;&gt; understand conceptually that perl data structures necessarily are designed<br/>&gt;&gt; to be used in such a runtime that requires &quot;bookkeeping&quot;. Worst case for me,<br/>&gt;&gt; I come away with a better understanding on why what I am asking actually is<br/>&gt;&gt; _impossible_.<br/>&gt; <br/>&gt;&gt; Can perl handle such a &quot;threaded&quot; block internally?<br/>&gt;&gt;<br/>&gt;&gt; The most likely answer I can project is:<br/>&gt;&gt;<br/>&gt;&gt; * not directly, an embedded &quot;SMP capable interpreter&quot; approach is the only<br/>&gt;&gt; clean way to do this.<br/>&gt; <br/>&gt; Sure, Perl doesn&#39;t have a GIL (Global Interpreter Lock), but it doesn&#39;t need<br/>&gt; to - it doesn&#39;t expose a concept of running more than one execution context<br/>&gt; on the same interpreter, which is what the Python GIL is about -<br/>&gt; time-slicing the single interpreter to run more than one execution context.<br/>&gt; (Non-concurrent parallelism. So just one CPU core)<br/>&gt; <br/>&gt; What you&#39;re describing would need more than one execution context able to<br/>&gt; run on the same interpreter. Right now there&#39;s a total assumption of 1-to-1<br/>&gt; mapping from interpreter to execution context. What differs from Python is<br/>&gt; that we *don&#39;t* have the assumption of exactly one interpreter in an OS<br/>&gt; process, all the C APIs are ready for this, and XS extensions likely should<br/>&gt; be.<br/>&gt; <br/>&gt; ithreads exploits this ability to have more than one interpreter to then<br/>&gt; provide more than one execution context (which is what we care about) which<br/>&gt; means that it can use more than one CPU.<br/>&gt; <br/>&gt; On Wed, Apr 07, 2021 at 11:20:49PM -0400, Dan Book wrote:<br/>&gt; <br/>&gt;&gt; I&#39;d defer to others more familiar with ithreads such as Nicholas&#39;s earlier<br/>&gt;&gt; post, but what you are describing is largely what threads.pm does, and its<br/>&gt;&gt; problems of being heavyweight to spawn and causing bugs largely stem from<br/>&gt;&gt; trying to share memory and have the perl interpreter available in each<br/>&gt;&gt; thread. So I&#39;ll just say, these are a lot of nice wishes, but getting the<br/>&gt;&gt; tradeoffs right in the implementation is a challenge, if it is possible at<br/>&gt;&gt; all.<br/>&gt; <br/>&gt; Yes. The *problem* is/remains that everything internally assumes/relies on<br/>&gt; &quot;interpreter&quot; === &quot;execution context&quot;, meaning that ithreads has to<br/>&gt; <br/>&gt; 1) rather expensively copy the entire interpreter to create a second<br/>&gt; execution context<br/>&gt; 2) there isn&#39;t a good way to share data between contexts<br/>&gt; <br/>&gt; To be viable, the threading model Brett is suggesting still needs the<br/>&gt; *first* point to be changed - it only works out if &quot;execution context&quot; is<br/>&gt; decoupled from &quot;interpreter state&quot;, and it becomes possible to have 2+<br/>&gt; execution contexts running concurrently on the same interpreter.<br/>&gt; <br/>&gt; ie *we* wouldn&#39;t have to solve:<br/>&gt; <br/>&gt; There should be one -- and preferably only one -- [interpreter]<br/>&gt; <br/>&gt; but the rest is effectively the same problem as removing the GIL.<br/>&gt; <br/>&gt; <br/>&gt; And that failed, despite considerable efforts<br/>&gt; <br/>&gt; The two talks by Larry Hastings on this are quite interesting (and fun to<br/>&gt; watch, as he is good at explaining things, and it&#39;s mostly not Python<br/>&gt; specific)<br/>&gt; <br/>&gt; In Removing Python&#39;s GIL: The Gilectomy - PyCon 2016<br/>&gt; at https://www.youtube.com/watch?v=P3AyI_u66Bw#t=19m45s<br/>&gt; <br/>&gt; he has a slide listing what you need to add locking to. Most of that maps<br/>&gt; one-to-one to the perl internals:<br/>&gt; <br/>&gt; * dicts =&gt; hashes (for symbol tables)<br/>&gt; * lists =&gt; arrays (many other interpreter global structures)<br/>&gt; * freelists =&gt; SV arenas<br/>&gt; <br/>&gt; <br/>&gt; He measured an immediate 30% slowdown *just* due to having to have reference<br/>&gt; counts now be implemented by CPU atomic operations.<br/>&gt; <br/>&gt; A year later, in his talk with the update, he notes that he&#39;s moved to<br/>&gt; buffered reference counting (and gives a very good explanation of this)<br/>&gt; <br/>&gt; Sufficient to say this approach makes DESTROY untimely. What&#39;s amusing is<br/>&gt; that in the Q&amp;A section he realises that he&#39;d missed saying something<br/>&gt; important:<br/>&gt; <br/>&gt; https://www.youtube.com/watch?v=pLqv11ScGsQ#t=41m20s<br/>&gt; <br/>&gt; The implication of buffered reference counting is that all refcount<br/>&gt; decrement to zero happens on the &quot;reference count committing thread&quot;. So,<br/>&gt; na??vely, this means that all DESTROY actions happen on that thread, which<br/>&gt; now has far too much work. Hence he uses queues to dispatch the destroy<br/>&gt; action *back* to the thread that did the last refcount decrement. Meaning<br/>&gt; that destruction is even more untimely.<br/>&gt; <br/>&gt; <br/>&gt; The sad part is that a year later, the update was that he&#39;d given up:<br/>&gt; <br/>&gt; He is &quot;out of bullets&quot; at least with that approach.<br/>&gt; <br/>&gt; With his complicated buffered-reference-count approach he was able to<br/>&gt; get his &quot;gilectomized&quot; interpreter to reach performance parity with<br/>&gt; CPython???except that his interpreter was running on around seven cores to<br/>&gt; keep up with CPython on one.<br/>&gt; <br/>&gt; https://lwn.net/Articles/754577/<br/>&gt; <br/>&gt; It&#39;s interesting that he then is considering that one would need to rewrite<br/>&gt; CPython from reference counting to a tracing garbage collector to get<br/>&gt; further, in that in another session at the same Python Language Summit<br/>&gt; someone from Instagram said that they experimented with exactly that:<br/>&gt; <br/>&gt; It is part of the C API, though, so reference counting must be<br/>&gt; maintained for C extensions; in the experiment, the Instagram developers<br/>&gt; moved to a tracing garbage collector everywhere else.<br/>&gt; <br/>&gt; https://lwn.net/Articles/754163/<br/>&gt; <br/>&gt; <br/>&gt; The Instagram folks also experimented with changing CPython&#39;s data<br/>&gt; structures to optimise for the common case, and saw speedups.<br/>&gt; (this obviously makes the C code more complex and harder to understand, but<br/>&gt; more importantly, this does start to break the C APIs, and hence existing<br/>&gt; extensions). Which is interesting, because at the end of his talk the<br/>&gt; previous year, Larry Hastings observed that Jython and IronPython can both<br/>&gt; linearly scale threads with CPUs. Both underlying VMs are written in C (or<br/>&gt; equivalent), hence an &quot;existence proof&quot; - it&#39;s clearly possible to scale<br/>&gt; linearly with a C implementation - it was just a question of how much the C<br/>&gt; API he needed to break to get there.<br/>&gt; <br/>&gt; So I&#39;m wondering (this is more [original arm waving] than [original<br/>&gt; research]), whether in effect Jython and IronPython are just taking the<br/>&gt; (equivalent) slowdown hit for concurrency as his Gilectomy, and then are<br/>&gt; able to win the speed back simply by using better data structures (optimised<br/>&gt; to the common runtime use patterns), because they aren&#39;t constrained by the<br/>&gt; C ABI.<br/>&gt; <br/>&gt; (Also they have JITs. But maybe more importantly, before that, they can<br/>&gt; specialise the bytecode executed at runtime to remove accessor calls, and do<br/>&gt; things like realise that some objects are not visible to other threads, or<br/>&gt; maybe don&#39;t even need to be on the heap. There are a lot of tricks that<br/>&gt; python, perl and VMs of that maturity don&#39;t and now can&#39;t use.)<br/>&gt; <br/>&gt; <br/>&gt; Also interesting on the Hacker News thread on the 2016 talk was this:<br/>&gt; <br/>&gt; I work on a new Ruby interpreter, and our solution to this problem has<br/>&gt; been to interpret the C code of extensions. That way we can give it one<br/>&gt; API, but really implement another.<br/>&gt; <br/>&gt; https://news.ycombinator.com/item?id=11845347<br/>&gt; <br/>&gt; This is &quot;Solang&quot;, &quot;system that can execute LLVM-based languages on the JVM&quot;:<br/>&gt; <br/>&gt; https://www.researchgate.net/publication/309443492_Bringing_low-level_languages_to_the_JVM_efficient_execution_of_LLVM_IR_on_Truffle<br/>&gt; https://www.youtube.com/watch?v=YLtjkP9bD_U<br/>&gt; <br/>&gt; Yes, this is crazy. Ruby needs to call C extensions. To make this efficient<br/>&gt; for Ruby running on the JVM, we&#39;ll just go compile the C into something we<br/>&gt; can (somehow) inline. And it worked. *<br/>&gt; <br/>&gt; However, again, despite all this very smart work, TruffleRuby doesn&#39;t seem<br/>&gt; to have taken over the world any more than JRuby did.<br/>&gt; <br/>&gt; Nor has PyPy taken over Python.<br/>&gt; <br/>&gt; Despite all these other smart folks working on problems similar to ours (eg<br/>&gt; at least 7 on TruffleRuby), I don&#39;t see any obvious strategy to steal.<br/>&gt; <br/>&gt; <br/>&gt; <br/>&gt; Sideways from this, I started to wonder how you might start to untangle the<br/>&gt; &quot;one interpreter&quot; === &quot;one execution context&quot;. The obvious start is to try<br/>&gt; to avoid reference counting overhead where possible. Most objects *aren&#39;t*<br/>&gt; visible to more than one thread. (In the degenerate case of one thread,<br/>&gt; that&#39;s all objects - this feels like a good start.). Hence have the concept<br/>&gt; of &quot;local objects&quot; and &quot;shared objects&quot; - it&#39;s just one flag bit. You *are<br/>&gt; going to need a branch for every reference count twiddle, but it might be<br/>&gt; faster, because mostly it will avoid atomic operations (or buffered<br/>&gt; reference counting, or whatever)<br/>&gt; <br/>&gt; Everything starts local - if an object becomes referenced by a shared<br/>&gt; object, that object must be promoted to &quot;shared&quot;. It&#39;s the same sort of idea<br/>&gt; as generational GC, and would also imply a write barrier on every<br/>&gt; assignment. That&#39;s a small CPU cost, but it&#39;s a new rule that XS code on<br/>&gt; CPAN doesn&#39;t know that it needs to conform to...<br/>&gt; <br/>&gt; But, stashes are global. So because of this invariant, subs are global, so<br/>&gt; pads are global, so all lexicals are global.<br/>&gt; <br/>&gt; Oh pants!<br/>&gt; <br/>&gt; Suddenly everything is global, without trying.<br/>&gt; <br/>&gt; <br/>&gt; And actually it&#39;s worse - pads aren&#39;t just global in this sense - they are<br/>&gt; one of these *implicit* assumptions of &quot;one is one&quot; - they are an array of<br/>&gt; arrays - the inner array is lexicals (and temporaries) for the subroutine,<br/>&gt; the outer array permits one of these for each depth of recursion.<br/>&gt; <br/>&gt; There&#39;s no way to have two threads execute the same subroutine<br/>&gt; simultaneously, without some major refactoring.<br/>&gt; <br/>&gt; (signatures, @_, return values on the stack, sending return values back from<br/>&gt; multiple threads to the master at the end - these are all problems, but<br/>&gt; trivial in comparison to things like this)<br/>&gt; <br/>&gt; On Fri, Apr 09, 2021 at 12:53:27AM -0500, B. Estrade wrote:<br/>&gt; <br/>&gt;&gt; For now, I want all of us to think &quot;thread safety&quot; and &quot;SMP&quot; in everything<br/>&gt;&gt; we do. Not in a design sense, in the unconsiousness sense; so it imbues<br/>&gt;&gt; itself in every aspect of any work and thinking done in the name of<br/>&gt;&gt; perl/Perl.<br/>&gt;&gt;<br/>&gt;&gt; If you ask me right now; in 2024, I&#39;d like to be able to do something as<br/>&gt;&gt; simple as this as a single OS process, but utilizing &quot;light weight&quot; OS<br/>&gt;&gt; threads (e.g., pthreads):<br/>&gt; <br/>&gt;&gt; my $num_threads = 8;<br/>&gt;&gt; map_r($num_threads) {<br/>&gt;&gt; local $thread_id = tid();<br/>&gt;&gt; local $bakery_ticket = atomic_var_update; # threads race<br/>&gt;&gt; # threads do stuff<br/>&gt;&gt; # .. and more stuff<br/>&gt;&gt; # ... and maybe more stuff<br/>&gt;&gt;<br/>&gt;&gt; # busy wait<br/>&gt;&gt; do {<br/>&gt;&gt; local $ihazbeenserved = now_serving($bakery_ticket);<br/>&gt;&gt; } while(not $ihazbeenserved);<br/>&gt;&gt;<br/>&gt;&gt; # &quot;safely&quot; print to STDOUT without clobbering (could use regular<br/>&gt;&gt; # printf and risk messages overlapping)<br/>&gt;&gt; printf_r(&quot;Yay! I, thread %d, now has my %s&quot;, $tid, $ihazbeenserved);<br/>&gt;&gt; }<br/>&gt; <br/>&gt; This isn&#39;t something that we can solve by working on it for the next few<br/>&gt; years - really it&#39;s something that could only be solved by working on it 25<br/>&gt; years ago, and having a radically different implementation.<br/>&gt; <br/>&gt; Basically, I don&#39;t think that the current Perl 5 internals are going to<br/>&gt; support CPU level parallelism in the same interpreter, any more than<br/>&gt; CPython ever will, or MRI.<br/>&gt; <br/>&gt; You *can* get to CPU level parallelism within &quot;leaf&quot; calls to C - so likely<br/>&gt; Yuki Kimoto&#39;s suggestion of SPVM seems interesting - he pasted the link to<br/>&gt; https://github.com/yuki-kimoto/SPVM/tree/master/examples/native/openmp<br/>&gt; <br/>&gt; For anything more than that, it&#39;s going to take other internals. For the<br/>&gt; syntax you&#39;re suggesting, the fastest route to seeing it run might be to<br/>&gt; look at https://github.com/rakudo-p5/v5 which aimed to write a Perl 5<br/>&gt; parser using Rakudo. I&#39;m aware that FROGGS stopped working on it a few<br/>&gt; years ago - I don&#39;t know how complete it is, but I don&#39;t think that there<br/>&gt; was any fundamental blocker.<br/>&gt; <br/>&gt; Nicholas Clark<br/>&gt; <br/>&gt; * There&#39;s a talk on it. You can watch the whole thing and just s/ruby/perl/g<br/>&gt; I had no idea that the Ruby C &quot;API&quot; was just like the Perl C &quot;API&quot;.<br/>&gt; <br/>&gt; Spoilers start here:<br/>&gt; Of the 2.1 billion lines of code in RubyGems, .5 billion is C.<br/>&gt; A ruby extension in C can be 10x faster than MRI<br/>&gt; Their approach is 15x faster than MRI *without* inlining C, 30x with.<br/>&gt; They actually implement much of the Ruby C ABI in Ruby.<br/>&gt; The Gem thinks that it&#39;s doing this:<br/>&gt; existing Gem written in C, compiled =&gt; C function in MRI<br/>&gt; when actually it&#39;s this:<br/>&gt; existing Gem unchanged, compiled to LLVM bytecode =&gt; their C shim =&gt; Ruby<br/>&gt; where *all* that is being run inside the JVM.<br/>&gt; <br/>&gt; The single best slide is this:<br/>&gt; https://www.youtube.com/watch?v=YLtjkP9bD_U&amp;t=266s<br/>&gt; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259773.html Fri, 09 Apr 2021 14:31:45 +0000 Re: on changing perl's behavior by Christian Walde On Fri, 09 Apr 2021 15:51:02 +0200, Martijn Lievaart &lt;m@rtij.nl&gt; wrote:<br/><br/>&gt; Op 09-04-2021 om 12:09 schreef Christian Walde:<br/>&gt;&gt; On Fri, 09 Apr 2021 11:51:33 +0200, Ovid &lt;curtis_ovid_poe@yahoo.com&gt;<br/>&gt;&gt; wrote:<br/>&gt;&gt;<br/>&gt;&gt;&gt; On Friday, 9 April 2021, 11:32:55 CEST, Christian Walde<br/>&gt;&gt;&gt; &lt;walde.christian@gmail.com&gt; wrote:<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt;&gt; There&#39;s a way to make everyone happy.<br/>&gt;&gt;&gt;&gt;<br/>&gt;&gt;&gt;&gt; Define `use 7;` and up as: &quot;doesn&#39;t provide format-related things&quot;.<br/>&gt;&gt;&gt;&gt;<br/>&gt;&gt;&gt;&gt; Define missing `use $v;` or one with $v &lt; 7 as: &quot;provides<br/>&gt;&gt;&gt;&gt; format-related things as they were pre-7&quot;.<br/>&gt;&gt;&gt;&gt;<br/>&gt;&gt;&gt;&gt; That way we don&#39;t step on any toes of format users, and Leonerd can<br/>&gt;&gt;&gt;&gt; create new syntax using format-danglies in v7+.<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; I am not sure I understand. Are you suggesting that if you want the<br/>&gt;&gt;&gt; benefit of v7 and you want formats, you&#39;re out of luck? Or are you<br/>&gt;&gt;&gt; suggesting you have to learn more boilerplate by explicitly not using<br/>&gt;&gt;&gt; &quot;v7&quot; but writing the boilerplate to get the benefits of v7+formats?<br/>&gt;&gt;&gt; That isn&#39;t better than what we have, so I think I&#39;ve misunderstood you.<br/>&gt;&gt;<br/>&gt;&gt; As long as Perl dialects $v &lt; 7 are still implemented in the<br/>&gt;&gt; interpreter you can do:<br/>&gt;&gt;<br/>&gt;&gt; use 7;<br/>&gt;&gt;<br/>&gt;&gt; sub do_format {<br/>&gt;&gt; use 5;<br/>&gt;&gt; format ...;<br/>&gt;&gt; write;<br/>&gt;&gt; }<br/>&gt;&gt;<br/>&gt;&gt; or<br/>&gt;&gt;<br/>&gt;&gt; sub do_format {<br/>&gt;&gt; format ...;<br/>&gt;&gt; write;<br/>&gt;&gt; }<br/>&gt;&gt;<br/>&gt;&gt; use 7;<br/>&gt;&gt;<br/>&gt;&gt; do_format();<br/>&gt;<br/>&gt; Or simply<br/>&gt;<br/>&gt; use 7;<br/>&gt; use feature &#39;format&#39;;<br/>&gt;<br/>&gt; sub do_format {<br/>&gt; format ...;<br/>&gt; write;<br/>&gt; }<br/>&gt;<br/>&gt;&gt; Only once it is decided that dialects $v &lt; 7 be deprecated would those<br/>&gt;&gt; stop to work.<br/>&gt;<br/>&gt; Which is decoupled if it is a feature.<br/><br/>Also nice, yes. :)<br/><br/>Or LeoNerd&#39;s work here. https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259769.html<br/><br/>Many ways to slice this carrot. :D<br/><br/>-- <br/>With regards,<br/>Christian Walde<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259772.html Fri, 09 Apr 2021 14:30:46 +0000 Re: on changing perl's behavior by Martijn Lievaart Op 09-04-2021 om 12:09 schreef Christian Walde:<br/>&gt; On Fri, 09 Apr 2021 11:51:33 +0200, Ovid &lt;curtis_ovid_poe@yahoo.com&gt; <br/>&gt; wrote:<br/>&gt;<br/>&gt;&gt; &nbsp;&nbsp; On Friday, 9 April 2021, 11:32:55 CEST, Christian Walde <br/>&gt;&gt; &lt;walde.christian@gmail.com&gt; wrote:<br/>&gt;&gt;<br/>&gt;&gt;&gt; There&#39;s a way to make everyone happy.<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; Define `use 7;` and up as: &quot;doesn&#39;t provide format-related things&quot;.<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; Define missing `use $v;` or one with $v &lt; 7 as: &quot;provides <br/>&gt;&gt;&gt; format-related things as they were pre-7&quot;.<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; That way we don&#39;t step on any toes of format users, and Leonerd can <br/>&gt;&gt;&gt; create new syntax using format-danglies in v7+.<br/>&gt;&gt;<br/>&gt;&gt; I am not sure I understand. Are you suggesting that if you want the <br/>&gt;&gt; benefit of v7 and you want formats, you&#39;re out of luck? Or are you <br/>&gt;&gt; suggesting you have to learn more boilerplate by explicitly not using <br/>&gt;&gt; &quot;v7&quot; but writing the boilerplate to get the benefits of v7+formats? <br/>&gt;&gt; That isn&#39;t better than what we have, so I think I&#39;ve misunderstood you.<br/>&gt;<br/>&gt; As long as Perl dialects $v &lt; 7 are still implemented in the <br/>&gt; interpreter you can do:<br/>&gt;<br/>&gt; &nbsp;&nbsp; use 7;<br/>&gt;<br/>&gt; &nbsp;&nbsp; sub do_format {<br/>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; use 5;<br/>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; format ...;<br/>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; write;<br/>&gt; &nbsp;&nbsp; }<br/>&gt;<br/>&gt; or<br/>&gt;<br/>&gt; &nbsp;&nbsp; sub do_format {<br/>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; format ...;<br/>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; write;<br/>&gt; &nbsp;&nbsp; }<br/>&gt;<br/>&gt; &nbsp;&nbsp; use 7;<br/>&gt;<br/>&gt; &nbsp;&nbsp; do_format();<br/><br/>Or simply<br/><br/> &nbsp;&nbsp; use 7;<br/> &nbsp;&nbsp; use feature &#39;format&#39;;<br/><br/> &nbsp;&nbsp; sub do_format {<br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; format ...;<br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; write;<br/> &nbsp;&nbsp; }<br/><br/><br/>&gt; Only once it is decided that dialects $v &lt; 7 be deprecated would those <br/>&gt; stop to work.<br/><br/><br/>Which is decoupled if it is a feature.<br/><br/><br/>HTH,<br/><br/>M4<br/><br/><br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259771.html Fri, 09 Apr 2021 13:51:18 +0000 Re: threads and stuff (was Re: =?utf-8?Q?P?==?utf-8?B?ZXJs4oCZcw==?= leaky bucket) by Nicholas Clark On Wed, Apr 07, 2021 at 08:49:31PM -0500, B. Estrade wrote:<br/>&gt; FWIW, I can accept that fundamentally this violates any number of basic<br/>&gt; assumptions in the perl runtime. I know it&#39;s interpreted, dynamic, etc. I<br/>&gt; understand conceptually that perl data structures necessarily are designed<br/>&gt; to be used in such a runtime that requires &quot;bookkeeping&quot;. Worst case for me,<br/>&gt; I come away with a better understanding on why what I am asking actually is<br/>&gt; _impossible_.<br/><br/>&gt; Can perl handle such a &quot;threaded&quot; block internally?<br/>&gt; <br/>&gt; The most likely answer I can project is:<br/>&gt; <br/>&gt; * not directly, an embedded &quot;SMP capable interpreter&quot; approach is the only<br/>&gt; clean way to do this.<br/><br/>Sure, Perl doesn&#39;t have a GIL (Global Interpreter Lock), but it doesn&#39;t need<br/>to - it doesn&#39;t expose a concept of running more than one execution context<br/>on the same interpreter, which is what the Python GIL is about -<br/>time-slicing the single interpreter to run more than one execution context.<br/>(Non-concurrent parallelism. So just one CPU core)<br/><br/>What you&#39;re describing would need more than one execution context able to<br/>run on the same interpreter. Right now there&#39;s a total assumption of 1-to-1<br/>mapping from interpreter to execution context. What differs from Python is<br/>that we *don&#39;t* have the assumption of exactly one interpreter in an OS<br/>process, all the C APIs are ready for this, and XS extensions likely should<br/>be.<br/><br/>ithreads exploits this ability to have more than one interpreter to then<br/>provide more than one execution context (which is what we care about) which<br/>means that it can use more than one CPU.<br/><br/>On Wed, Apr 07, 2021 at 11:20:49PM -0400, Dan Book wrote:<br/><br/>&gt; I&#39;d defer to others more familiar with ithreads such as Nicholas&#39;s earlier<br/>&gt; post, but what you are describing is largely what threads.pm does, and its<br/>&gt; problems of being heavyweight to spawn and causing bugs largely stem from<br/>&gt; trying to share memory and have the perl interpreter available in each<br/>&gt; thread. So I&#39;ll just say, these are a lot of nice wishes, but getting the<br/>&gt; tradeoffs right in the implementation is a challenge, if it is possible at<br/>&gt; all.<br/><br/>Yes. The *problem* is/remains that everything internally assumes/relies on<br/>&quot;interpreter&quot; === &quot;execution context&quot;, meaning that ithreads has to<br/><br/>1) rather expensively copy the entire interpreter to create a second<br/> execution context<br/>2) there isn&#39;t a good way to share data between contexts<br/><br/>To be viable, the threading model Brett is suggesting still needs the<br/>*first* point to be changed - it only works out if &quot;execution context&quot; is<br/>decoupled from &quot;interpreter state&quot;, and it becomes possible to have 2+<br/>execution contexts running concurrently on the same interpreter.<br/><br/>ie *we* wouldn&#39;t have to solve:<br/><br/> There should be one -- and preferably only one -- [interpreter]<br/><br/>but the rest is effectively the same problem as removing the GIL.<br/><br/><br/>And that failed, despite considerable efforts<br/><br/>The two talks by Larry Hastings on this are quite interesting (and fun to<br/>watch, as he is good at explaining things, and it&#39;s mostly not Python<br/>specific)<br/><br/>In Removing Python&#39;s GIL: The Gilectomy - PyCon 2016<br/>at https://www.youtube.com/watch?v=P3AyI_u66Bw#t=19m45s<br/><br/>he has a slide listing what you need to add locking to. Most of that maps<br/>one-to-one to the perl internals:<br/><br/>* dicts =&gt; hashes (for symbol tables)<br/>* lists =&gt; arrays (many other interpreter global structures)<br/>* freelists =&gt; SV arenas<br/><br/><br/>He measured an immediate 30% slowdown *just* due to having to have reference<br/>counts now be implemented by CPU atomic operations.<br/><br/>A year later, in his talk with the update, he notes that he&#39;s moved to<br/>buffered reference counting (and gives a very good explanation of this)<br/><br/>Sufficient to say this approach makes DESTROY untimely. What&#39;s amusing is<br/>that in the Q&amp;A section he realises that he&#39;d missed saying something<br/>important:<br/><br/>https://www.youtube.com/watch?v=pLqv11ScGsQ#t=41m20s<br/><br/>The implication of buffered reference counting is that all refcount<br/>decrement to zero happens on the &quot;reference count committing thread&quot;. So,<br/>na??vely, this means that all DESTROY actions happen on that thread, which<br/>now has far too much work. Hence he uses queues to dispatch the destroy<br/>action *back* to the thread that did the last refcount decrement. Meaning<br/>that destruction is even more untimely.<br/><br/><br/>The sad part is that a year later, the update was that he&#39;d given up:<br/><br/> He is &quot;out of bullets&quot; at least with that approach.<br/><br/> With his complicated buffered-reference-count approach he was able to<br/> get his &quot;gilectomized&quot; interpreter to reach performance parity with<br/> CPython???except that his interpreter was running on around seven cores to<br/> keep up with CPython on one.<br/> <br/>https://lwn.net/Articles/754577/<br/><br/>It&#39;s interesting that he then is considering that one would need to rewrite<br/>CPython from reference counting to a tracing garbage collector to get<br/>further, in that in another session at the same Python Language Summit<br/>someone from Instagram said that they experimented with exactly that:<br/><br/> It is part of the C API, though, so reference counting must be<br/> maintained for C extensions; in the experiment, the Instagram developers<br/> moved to a tracing garbage collector everywhere else.<br/><br/>https://lwn.net/Articles/754163/<br/><br/><br/>The Instagram folks also experimented with changing CPython&#39;s data<br/>structures to optimise for the common case, and saw speedups.<br/>(this obviously makes the C code more complex and harder to understand, but<br/>more importantly, this does start to break the C APIs, and hence existing<br/>extensions). Which is interesting, because at the end of his talk the<br/>previous year, Larry Hastings observed that Jython and IronPython can both<br/>linearly scale threads with CPUs. Both underlying VMs are written in C (or<br/>equivalent), hence an &quot;existence proof&quot; - it&#39;s clearly possible to scale<br/>linearly with a C implementation - it was just a question of how much the C<br/>API he needed to break to get there.<br/><br/>So I&#39;m wondering (this is more [original arm waving] than [original<br/>research]), whether in effect Jython and IronPython are just taking the<br/>(equivalent) slowdown hit for concurrency as his Gilectomy, and then are<br/>able to win the speed back simply by using better data structures (optimised<br/>to the common runtime use patterns), because they aren&#39;t constrained by the<br/>C ABI.<br/><br/>(Also they have JITs. But maybe more importantly, before that, they can<br/>specialise the bytecode executed at runtime to remove accessor calls, and do<br/>things like realise that some objects are not visible to other threads, or<br/>maybe don&#39;t even need to be on the heap. There are a lot of tricks that<br/>python, perl and VMs of that maturity don&#39;t and now can&#39;t use.)<br/><br/><br/>Also interesting on the Hacker News thread on the 2016 talk was this:<br/><br/> I work on a new Ruby interpreter, and our solution to this problem has<br/> been to interpret the C code of extensions. That way we can give it one<br/> API, but really implement another.<br/><br/>https://news.ycombinator.com/item?id=11845347<br/><br/>This is &quot;Solang&quot;, &quot;system that can execute LLVM-based languages on the JVM&quot;:<br/><br/>https://www.researchgate.net/publication/309443492_Bringing_low-level_languages_to_the_JVM_efficient_execution_of_LLVM_IR_on_Truffle<br/>https://www.youtube.com/watch?v=YLtjkP9bD_U<br/><br/>Yes, this is crazy. Ruby needs to call C extensions. To make this efficient<br/>for Ruby running on the JVM, we&#39;ll just go compile the C into something we<br/>can (somehow) inline. And it worked. *<br/><br/>However, again, despite all this very smart work, TruffleRuby doesn&#39;t seem<br/>to have taken over the world any more than JRuby did.<br/><br/>Nor has PyPy taken over Python.<br/><br/>Despite all these other smart folks working on problems similar to ours (eg<br/>at least 7 on TruffleRuby), I don&#39;t see any obvious strategy to steal.<br/><br/><br/><br/>Sideways from this, I started to wonder how you might start to untangle the<br/>&quot;one interpreter&quot; === &quot;one execution context&quot;. The obvious start is to try<br/>to avoid reference counting overhead where possible. Most objects *aren&#39;t*<br/>visible to more than one thread. (In the degenerate case of one thread,<br/>that&#39;s all objects - this feels like a good start.). Hence have the concept<br/>of &quot;local objects&quot; and &quot;shared objects&quot; - it&#39;s just one flag bit. You *are<br/>going to need a branch for every reference count twiddle, but it might be<br/>faster, because mostly it will avoid atomic operations (or buffered<br/>reference counting, or whatever)<br/><br/>Everything starts local - if an object becomes referenced by a shared<br/>object, that object must be promoted to &quot;shared&quot;. It&#39;s the same sort of idea<br/>as generational GC, and would also imply a write barrier on every<br/>assignment. That&#39;s a small CPU cost, but it&#39;s a new rule that XS code on<br/>CPAN doesn&#39;t know that it needs to conform to...<br/><br/>But, stashes are global. So because of this invariant, subs are global, so<br/>pads are global, so all lexicals are global.<br/><br/>Oh pants!<br/><br/>Suddenly everything is global, without trying.<br/><br/><br/>And actually it&#39;s worse - pads aren&#39;t just global in this sense - they are<br/>one of these *implicit* assumptions of &quot;one is one&quot; - they are an array of<br/>arrays - the inner array is lexicals (and temporaries) for the subroutine,<br/>the outer array permits one of these for each depth of recursion.<br/><br/>There&#39;s no way to have two threads execute the same subroutine<br/>simultaneously, without some major refactoring.<br/><br/>(signatures, @_, return values on the stack, sending return values back from<br/>multiple threads to the master at the end - these are all problems, but<br/>trivial in comparison to things like this)<br/><br/>On Fri, Apr 09, 2021 at 12:53:27AM -0500, B. Estrade wrote:<br/><br/>&gt; For now, I want all of us to think &quot;thread safety&quot; and &quot;SMP&quot; in everything<br/>&gt; we do. Not in a design sense, in the unconsiousness sense; so it imbues<br/>&gt; itself in every aspect of any work and thinking done in the name of<br/>&gt; perl/Perl.<br/>&gt; <br/>&gt; If you ask me right now; in 2024, I&#39;d like to be able to do something as<br/>&gt; simple as this as a single OS process, but utilizing &quot;light weight&quot; OS<br/>&gt; threads (e.g., pthreads):<br/><br/>&gt; my $num_threads = 8;<br/>&gt; map_r($num_threads) {<br/>&gt; local $thread_id = tid();<br/>&gt; local $bakery_ticket = atomic_var_update; # threads race<br/>&gt; # threads do stuff<br/>&gt; # .. and more stuff<br/>&gt; # ... and maybe more stuff<br/>&gt; <br/>&gt; # busy wait<br/>&gt; do {<br/>&gt; local $ihazbeenserved = now_serving($bakery_ticket);<br/>&gt; } while(not $ihazbeenserved);<br/>&gt; <br/>&gt; # &quot;safely&quot; print to STDOUT without clobbering (could use regular<br/>&gt; # printf and risk messages overlapping)<br/>&gt; printf_r(&quot;Yay! I, thread %d, now has my %s&quot;, $tid, $ihazbeenserved);<br/>&gt; }<br/><br/>This isn&#39;t something that we can solve by working on it for the next few<br/>years - really it&#39;s something that could only be solved by working on it 25<br/>years ago, and having a radically different implementation.<br/><br/>Basically, I don&#39;t think that the current Perl 5 internals are going to<br/>support CPU level parallelism in the same interpreter, any more than<br/>CPython ever will, or MRI.<br/><br/>You *can* get to CPU level parallelism within &quot;leaf&quot; calls to C - so likely<br/>Yuki Kimoto&#39;s suggestion of SPVM seems interesting - he pasted the link to<br/>https://github.com/yuki-kimoto/SPVM/tree/master/examples/native/openmp<br/><br/>For anything more than that, it&#39;s going to take other internals. For the<br/>syntax you&#39;re suggesting, the fastest route to seeing it run might be to<br/>look at https://github.com/rakudo-p5/v5 which aimed to write a Perl 5<br/>parser using Rakudo. I&#39;m aware that FROGGS stopped working on it a few<br/>years ago - I don&#39;t know how complete it is, but I don&#39;t think that there<br/>was any fundamental blocker.<br/><br/>Nicholas Clark<br/><br/>* There&#39;s a talk on it. You can watch the whole thing and just s/ruby/perl/g<br/> I had no idea that the Ruby C &quot;API&quot; was just like the Perl C &quot;API&quot;.<br/><br/> Spoilers start here:<br/> Of the 2.1 billion lines of code in RubyGems, .5 billion is C.<br/> A ruby extension in C can be 10x faster than MRI<br/> Their approach is 15x faster than MRI *without* inlining C, 30x with.<br/> They actually implement much of the Ruby C ABI in Ruby.<br/> The Gem thinks that it&#39;s doing this:<br/> existing Gem written in C, compiled =&gt; C function in MRI<br/> when actually it&#39;s this:<br/> existing Gem unchanged, compiled to LLVM bytecode =&gt; their C shim =&gt; Ruby<br/> where *all* that is being run inside the JVM.<br/><br/> The single best slide is this:<br/> https://www.youtube.com/watch?v=YLtjkP9bD_U&amp;t=266s<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259770.html Fri, 09 Apr 2021 13:31:45 +0000 Re: on changing perl's behavior by Paul "LeoNerd" Evans On Thu, 08 Apr 2021 22:23:43 -0400<br/>&quot;Ricardo Signes&quot; &lt;perl.p5p@rjbs.manxome.org&gt; wrote:<br/><br/>&gt; On Thu, Apr 8, 2021, at 5:18 PM, Todd Rinaldo wrote:<br/>&gt; &gt;&gt; Outside of that, when a huge win can be demonstrated, stuff should<br/>&gt; &gt;&gt; be removed, but then i&#39;d prefer it be done by way of deprecating<br/>&gt; &gt;&gt; that specific dialect. <br/>&gt; &gt; <br/>&gt; &gt; I would argue (though it&#39;s hard to search for &quot;format&quot; in the<br/>&gt; &gt; issues list) that being able to close 50+ cases would be nice if we<br/>&gt; &gt; could just say: &quot;Formats are removed. this issue is now<br/>&gt; &gt; irrelevant.&quot; <br/>&gt; <br/>&gt; I think that&#39;s true, strictly speaking, but: of the people who use<br/>&gt; formats, how many would be impacted, and how, if we removed formats?<br/>&gt; Well, 100% of them would be impacted, and the impact would be &quot;I had<br/>&gt; to rewrite some code&quot; which (given how formats work) would probably<br/>&gt; be kind of a pain in the butt. Sometimes a big one, sometimes pretty<br/>&gt; tiny.<br/><br/>In terms of eating into syntax we&#39;d like to use for other things,<br/>formats consume two keywords that aren&#39;t *that* interesting (`format`<br/>and `write`), and a bunch of variables; some of which we&#39;d quite like<br/>to reclaim for syntax purposes.<br/><br/>I have a branch that provides a (default-on) feature for parsing of the<br/>format-related variables, so that a future perl can simply<br/><br/> no feature &#39;format_vars&#39;;<br/><br/>to get all those back.<br/><br/> https://github.com/Perl/perl5/tree/leonerd/feature-format-vars<br/><br/>-- <br/>Paul &quot;LeoNerd&quot; Evans<br/><br/>leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS<br/>http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259769.html Fri, 09 Apr 2021 12:03:19 +0000 Re: on changing perl's behavior by Christian Walde On Fri, 09 Apr 2021 11:51:33 +0200, Ovid &lt;curtis_ovid_poe@yahoo.com&gt; wrote:<br/><br/>&gt; On Friday, 9 April 2021, 11:32:55 CEST, Christian Walde &lt;walde.christian@gmail.com&gt; wrote:<br/>&gt;<br/>&gt;&gt; There&#39;s a way to make everyone happy.<br/>&gt;&gt;<br/>&gt;&gt; Define `use 7;` and up as: &quot;doesn&#39;t provide format-related things&quot;.<br/>&gt;&gt;<br/>&gt;&gt; Define missing `use $v;` or one with $v &lt; 7 as: &quot;provides format-related things as they were pre-7&quot;.<br/>&gt;&gt;<br/>&gt;&gt; That way we don&#39;t step on any toes of format users, and Leonerd can create new syntax using format-danglies in v7+.<br/>&gt;<br/>&gt; I am not sure I understand. Are you suggesting that if you want the benefit of v7 and you want formats, you&#39;re out of luck? Or are you suggesting you have to learn more boilerplate by explicitly not using &quot;v7&quot; but writing the boilerplate to get the benefits of v7+formats? That isn&#39;t better than what we have, so I think I&#39;ve misunderstood you.<br/><br/>As long as Perl dialects $v &lt; 7 are still implemented in the interpreter you can do:<br/><br/> use 7;<br/><br/> sub do_format {<br/> use 5;<br/> format ...;<br/> write;<br/> }<br/><br/>or<br/><br/> sub do_format {<br/> format ...;<br/> write;<br/> }<br/><br/> use 7;<br/><br/> do_format();<br/><br/>Only once it is decided that dialects $v &lt; 7 be deprecated would those stop to work.<br/><br/>-- <br/>With regards,<br/>Christian Walde<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259768.html Fri, 09 Apr 2021 10:09:21 +0000 Re: on changing perl's behavior by Ovid via perl5-porters On Friday, 9 April 2021, 11:32:55 CEST, Christian Walde &lt;walde.christian@gmail.com&gt; wrote: <br/> <br/>&gt; There&#39;s a way to make everyone happy. <br/>&gt; <br/>&gt; Define `use 7;` and up as: &quot;doesn&#39;t provide format-related things&quot;. <br/>&gt; <br/>&gt; Define missing `use $v;` or one with $v &lt; 7 as: &quot;provides format-related things as they were pre-7&quot;. <br/>&gt; <br/>&gt; That way we don&#39;t step on any toes of format users, and Leonerd can create new syntax using format-danglies in v7+. <br/> <br/>I am not sure I understand. Are you suggesting that if you want the benefit of v7 and you want formats, you&#39;re out of luck? Or are you suggesting you have to learn more boilerplate by explicitly not using &quot;v7&quot; but writing the boilerplate to get the benefits of v7+formats? That isn&#39;t better than what we have, so I think I&#39;ve misunderstood you. <br/> <br/>Best,Ovid <br/>--&nbsp;IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/.&nbsp; <br/>Buy my book! - http://bit.ly/beginning_perl <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259767.html Fri, 09 Apr 2021 09:51:47 +0000 by Veesh Goldman I like the idea of having a repo with sample future code! I&#39;ll probably <br/>submit the sort of thing I&#39;m thinking of, too. <br/> <br/>On Fri, Apr 9, 2021, 10:26 B. Estrade &lt;brett@cpanel.net&gt; wrote: <br/> <br/>&gt; Even when I make up the rules, I still write terrible code in a rush. <br/>&gt; <br/>&gt; https://github.com/oodler577/p5-fan-fiction/blob/master/01/01-hello.pl <br/>&gt; https://github.com/oodler577/p5-fan-fiction/blob/master/01/02-bakery.pl <br/>&gt; <br/>&gt; And I figured, why should I have all the fun. If anyone is so inclined, <br/>&gt; follow the writing prompt and proceed. Remember, this is all pretend. I <br/>&gt; did clean up my off the cuff examples as best as I could... <br/>&gt; <br/>&gt; Challenge 01 (of possibly 1) - how would you write &quot;threaded&quot; perl [see <br/>&gt; writing prompt]? <br/>&gt; <br/>&gt; https://github.com/oodler577/p5-fan-fiction/blob/master/01/00-PROMPT.pod <br/>&gt; <br/>&gt; Enjoy. <br/>&gt; <br/>&gt; Brett <br/>&gt; <br/>&gt; On 4/9/21 12:53 AM, B. Estrade wrote: <br/>&gt; &gt; <br/>&gt; &gt; <br/>&gt; &gt; On 4/8/21 11:50 PM, Yuki Kimoto wrote: <br/>&gt; &gt;&gt; B. Estrade <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; I don&#39;t yet understand what you want. <br/>&gt; &gt; <br/>&gt; &gt; You and me both. What I *want* and what I think we have to do to get <br/>&gt; &gt; there are two vastly different things. <br/>&gt; &gt; <br/>&gt; &gt; For now, I want all of us to think &quot;thread safety&quot; and &quot;SMP&quot; in <br/>&gt; &gt; everything we do. Not in a design sense, in the unconsiousness sense; so <br/>&gt; &gt; it imbues itself in every aspect of any work and thinking done in the <br/>&gt; &gt; name of perl/Perl. <br/>&gt; &gt; <br/>&gt; &gt; If you ask me right now; in 2024, I&#39;d like to be able to do something as <br/>&gt; &gt; simple as this as a single OS process, but utilizing &quot;light weight&quot; OS <br/>&gt; &gt; threads (e.g., pthreads): <br/>&gt; &gt; <br/>&gt; &gt; #!/usr/bin/env perl <br/>&gt; &gt; use strict; <br/>&gt; &gt; use warnings; <br/>&gt; &gt; use v12; <br/>&gt; &gt; <br/>&gt; &gt; # &#39;traditional perl code&#39; <br/>&gt; &gt; #... <br/>&gt; &gt; # <br/>&gt; &gt; <br/>&gt; &gt; my_r $mailbox_rref = []; <br/>&gt; &gt; map_r(8) { <br/>&gt; &gt; local $thread_id = tid(); <br/>&gt; &gt; $mailbox_rref-&gt;[$thread_id] = qq{Hello from thread #$thread_id}; <br/>&gt; &gt; } <br/>&gt; &gt; foreach my $msg (@$mailbox_ref) { <br/>&gt; &gt; say $msg; <br/>&gt; &gt; } <br/>&gt; &gt; <br/>&gt; &gt; Output: <br/>&gt; &gt; <br/>&gt; &gt; Hello from thread # 0 <br/>&gt; &gt; Hello from thread # 1 <br/>&gt; &gt; Hello from thread # 2 <br/>&gt; &gt; Hello from thread # 3 <br/>&gt; &gt; Hello from thread # 4 <br/>&gt; &gt; Hello from thread # 5 <br/>&gt; &gt; Hello from thread # 6 <br/>&gt; &gt; Hello from thread # 7 <br/>&gt; &gt; <br/>&gt; &gt; Another example, <br/>&gt; &gt; <br/>&gt; &gt; #!/usr/bin/env perl <br/>&gt; &gt; use strict; <br/>&gt; &gt; use warnings; <br/>&gt; &gt; use v12; <br/>&gt; &gt; <br/>&gt; &gt; # &#39;traditional perl code&#39; <br/>&gt; &gt; #... <br/>&gt; &gt; # <br/>&gt; &gt; <br/>&gt; &gt; sub state_var_update { <br/>&gt; &gt; state $ret = 0; <br/>&gt; &gt; return ++$ret; <br/>&gt; &gt; } <br/>&gt; &gt; <br/>&gt; &gt; sub atomic_var_update { <br/>&gt; &gt; atomic $ret = 0; # like &#39;state&#39; but actions upon it are atomic <br/>&gt; &gt; return ++$ret; # atomic nature forces unordered serialization <br/>&gt; &gt; } <br/>&gt; &gt; <br/>&gt; &gt; sub now_serving { <br/>&gt; &gt; state $now_serving = 0; <br/>&gt; &gt; my $ticket = shift; <br/>&gt; &gt; return undef if $ticket != $now_serving; <br/>&gt; &gt; return q{You&#39;ve been served a nice warm rye loaf!}; <br/>&gt; &gt; } <br/>&gt; &gt; <br/>&gt; &gt; my $num_threads = 8; <br/>&gt; &gt; map_r($num_threads) { <br/>&gt; &gt; local $thread_id = tid(); <br/>&gt; &gt; local $bakery_ticket = atomic_var_update; # threads race <br/>&gt; &gt; # threads do stuff <br/>&gt; &gt; # .. and more stuff <br/>&gt; &gt; # ... and maybe more stuff <br/>&gt; &gt; <br/>&gt; &gt; # busy wait <br/>&gt; &gt; do { <br/>&gt; &gt; local $ihazbeenserved = now_serving($bakery_ticket); <br/>&gt; &gt; } while(not $ihazbeenserved); <br/>&gt; &gt; <br/>&gt; &gt; # &quot;safely&quot; print to STDOUT without clobbering (could use regular <br/>&gt; &gt; # printf and risk messages overlapping) <br/>&gt; &gt; printf_r(&quot;Yay! I, thread %d, now has my %s&quot;, $tid, $ihazbeenserved); <br/>&gt; &gt; } <br/>&gt; &gt; <br/>&gt; &gt; # had to google for the following <br/>&gt; &gt; format STUDENT = <br/>&gt; &gt; =================================== <br/>&gt; &gt; @&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; @&lt;&lt; <br/>&gt; &gt; $name $age <br/>&gt; &gt; @#####.## <br/>&gt; &gt; $fee <br/>&gt; &gt; =================================== <br/>&gt; &gt; . <br/>&gt; &gt; <br/>&gt; &gt; select(STDOUT); <br/>&gt; &gt; $~ = STUDENT; <br/>&gt; &gt; <br/>&gt; &gt; @n = (&quot;Deepak&quot;, &quot;Rajat&quot;, &quot;Vikrant&quot;); <br/>&gt; &gt; @a = (18, 16, 14); <br/>&gt; &gt; @s = (2000.00, 2500.00, 4000.000); <br/>&gt; &gt; <br/>&gt; &gt; $i = 0; <br/>&gt; &gt; foreach (@n) <br/>&gt; &gt; { <br/>&gt; &gt; $name = $_; <br/>&gt; &gt; $age = $a[$i]; <br/>&gt; &gt; $fee = $s[$i++]; <br/>&gt; &gt; write; <br/>&gt; &gt; } <br/>&gt; &gt; <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; If you want to call OpenMP easily, I&#39;m also trying in my SPVM module. <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; https://github.com/yuki-kimoto/SPVM/tree/master/examples/native/openmp <br/>&gt; &gt;&gt; <br/>&gt; &gt; <br/>&gt; &gt; I saw your module come through on metacpan under &quot;recent&quot; and it looked <br/>&gt; &gt; very interesting. I&#39;ll look deeper into it. <br/>&gt; &gt; <br/>&gt; &gt;&gt; Perl already has Inline::C/XS/FFIs modules. SPVM is another way to <br/>&gt; &gt;&gt; bind C libraries. <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; More example <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; -cuda <br/>&gt; &gt;&gt; -Eigen <br/>&gt; &gt;&gt; -GSL <br/>&gt; &gt;&gt; -OpenCV <br/>&gt; &gt;&gt; -zlib <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; https://github.com/yuki-kimoto/SPVM/tree/master/examples/native <br/>&gt; &gt; <br/>&gt; &gt; Yes, very nice. I will look at it. Whereas what I want and what I am <br/>&gt; &gt; playing with are vastly different, I am also very interested in FFI type <br/>&gt; &gt; support for leveraging SMP, GPUs (not really myself but it&#39;s important), <br/>&gt; &gt; etc. <br/>&gt; &gt; <br/>&gt; &gt; My two examples above point to a few things: <br/>&gt; &gt; <br/>&gt; &gt; 0. &#39;_r&#39; indicates &quot;thread safe&quot; - this is an old tradition from IBM; <br/>&gt; &gt; google it, it&#39;s a thing; I promise. <br/>&gt; &gt; <br/>&gt; &gt; 1. atomic data types (thread safe) that in addition to providing for <br/>&gt; &gt; &quot;safe&quot; updates (one thread at a time), can serve as barriers <br/>&gt; &gt; (serialization points) <br/>&gt; &gt; <br/>&gt; &gt; 2. a map_r (or similar) construct that provides a threaded environment; <br/>&gt; &gt; yes, I know &#39;map_r&#39; also implies a lot of things related to the existing <br/>&gt; &gt; &#39;map&#39;; that&#39;d be cool to, but it seemed like a more apt name that what I <br/>&gt; &gt; had originally, &#39;fork_r&#39;. <br/>&gt; &gt; <br/>&gt; &gt; 3. ability for threads to call all subs &quot;unsafely&quot; (race condition); but <br/>&gt; &gt; with the judicious use of atomics can provide barriers to keep things <br/>&gt; &gt; <br/>&gt; &gt; 4. thread safe analogs to things like printf (see inline comment in code <br/>&gt; &gt; above) <br/>&gt; &gt; <br/>&gt; &gt; 5. the use of &#39;format&#39; was just because I&#39;ve never used it before and <br/>&gt; &gt; had just googled it to see what it&#39;s all about :) <br/>&gt; &gt; <br/>&gt; &gt; I quite enjoyed coming up these examples, and I might even as an <br/>&gt; &gt; exercise try to come up with many more so that when asked - &quot;what do you <br/>&gt; &gt; mean&quot; or &quot;show me an example&quot; of what you are thinking, I can point to <br/>&gt; &gt; that. <br/>&gt; &gt; <br/>&gt; &gt; Even after this thought exercise, I am beginning to see how a mix of the <br/>&gt; &gt; following might point us in the right direction (and through the <br/>&gt; &gt; minefield that is the perl runtime): <br/>&gt; &gt; <br/>&gt; &gt; * a threaded block (above it&#39;s map_r, could be fork_r, or just spawner, <br/>&gt; &gt; etc) <br/>&gt; &gt; * thread safe forms of: <br/>&gt; &gt; - scalar reference; declared with &#39;my_r&#39;, array ref or hash ref on <br/>&gt; &gt; the other end is assumed to be a &#39;thread safe&#39; anonymous array or hash <br/>&gt; &gt; - arrays - slots can be updated in a threaded environment (threads <br/>&gt; &gt; can be unsafe and simultaneously update an element; but that&#39;s the risk <br/>&gt; &gt; with SMP) <br/>&gt; &gt; - hash - same concept as &#39;thread safe&#39; array, but hash <br/>&gt; &gt; - atomic - an actual scalar value that can be safely updated; it&#39;s <br/>&gt; &gt; primary use is as a synchronization point; default access is &quot;unordered&quot; <br/>&gt; &gt; meaning first thread there wins, then all others line up <br/>&gt; &gt; non-deterministically; there should probably be an way to &#39;order&#39; <br/>&gt; &gt; threads based on tid() in some efficient way <br/>&gt; &gt; <br/>&gt; &gt; Other thoughts, <br/>&gt; &gt; <br/>&gt; &gt; * sub_r: thread safe form of &#39;sub&#39; that has a serialization effect as <br/>&gt; &gt; well, except it is run by only one thread at a time (user is allowed to <br/>&gt; &gt; do unsafe things using perl&#39;s traditional scoping rules) - akin to an <br/>&gt; &gt; OpenMP &#39;critical&#39; section. <br/>&gt; &gt; <br/>&gt; &gt; Anyway, thanks for asking. I&#39;ll think more about it and see if I can <br/>&gt; &gt; flesh it out more. <br/>&gt; &gt; <br/>&gt; &gt; Note, I am not going for any particular concurrency model. I am going <br/>&gt; &gt; for &quot;what does SMP look like in perl5&quot;. I think I have a good idea, and <br/>&gt; &gt; the &#39;_r&#39; stuff and atomic(s) are merely language additions to get around <br/>&gt; &gt; affecting &quot;serial&quot; perl. (no I don&#39;t want a perl_r; just for the record). <br/>&gt; &gt; <br/>&gt; &gt; Brett <br/>&gt; &gt; <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; 2021&aring;&sup1;&acute;4&aelig;&#156;&#136;9&aelig;&#151;&yen;(&eacute;&#135;&#145;) 0:05 B. Estrade &lt;brett@cpanel.net <br/>&gt; &gt;&gt; &lt;mailto:brett@cpanel.net&gt;&gt;: <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; Thank you, appreciate the reply. To avoid collision with the other <br/>&gt; &gt;&gt; thread, I update the subject. <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; So I suppose this cuts to the heart of the matter. It&#39;s fair, I <br/>&gt; &gt;&gt; believe, <br/>&gt; &gt;&gt; that &quot;top level &#39;threading&#39;&quot; is not something that can be reasonable <br/>&gt; &gt;&gt; supported in the perl runtime (and to be fair, other scripting <br/>&gt; &gt;&gt; languages <br/>&gt; &gt;&gt; also struggle greatly with this). <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; The question, then goes to: how do we facilitate access to the <br/>&gt; native <br/>&gt; &gt;&gt; platform&#39;s SMP? Perhaps the answer is, as always, &quot;it depends.&quot; <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; I will continue to pound my head on this, something will shake <br/>&gt; &gt;&gt; loose. In <br/>&gt; &gt;&gt; the meantime, as proof that I am vested in seeing some interesting <br/>&gt; &gt;&gt; options shake loose, I have offered a module on CPAN called <br/>&gt; &gt;&gt; OpenMP::Environment. <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; It only provides programmatic manipulation of the environmental <br/>&gt; &gt;&gt; variables that OpenMP programs care about; but it is a necessary <br/>&gt; step <br/>&gt; &gt;&gt; for me to investigate and gain some intuition about what is possible <br/>&gt; &gt;&gt; and <br/>&gt; &gt;&gt; what looks &quot;right&quot;. <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; Currently I am thinking a SIMD (single instruction, multiple data) <br/>&gt; &gt;&gt; approach is the most accessible. This doesn&#39;t really get at what is <br/>&gt; &gt;&gt; ideal (in my mind), but at least provides a path forward by creating <br/>&gt; &gt;&gt; threaded libraries made available via Inline::C/XS/FFIs - and even <br/>&gt; &gt;&gt; leveraging these via a tie interface. And if the direction of <br/>&gt; &gt;&gt; providing <br/>&gt; &gt;&gt; SIMD &quot;data types&quot; is truly the best direction, PDL seems like a <br/>&gt; &gt;&gt; really <br/>&gt; &gt;&gt; good target for that. <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; Thanks for all the feedback, will monitor the list/thread. I do ask <br/>&gt; &gt;&gt; that <br/>&gt; &gt;&gt; we keep the whole idea of threading &quot;where and when feasible&quot; <br/>&gt; &gt;&gt; (even in <br/>&gt; &gt;&gt; language design considerations) is extremely important to Perl&#39;s <br/>&gt; long <br/>&gt; &gt;&gt; term viability and as a driver of important capabilities. The idea <br/>&gt; of <br/>&gt; &gt;&gt; using Perl to efficiently max out a large SMP machine for useful <br/>&gt; &gt;&gt; work is <br/>&gt; &gt;&gt; very exciting to me, and I think I am not the only one. <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; Cheers, <br/>&gt; &gt;&gt; Brett <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; <br/>&gt; &gt;&gt; On 4/8/21 3:42 AM, Konovalov, Vadim wrote: <br/>&gt; &gt;&gt; &gt;&gt; Nicholas Clark &lt;nick@ccl4.org &lt;mailto:nick@ccl4.org&gt;&gt; wrote: <br/>&gt; &gt;&gt; &gt;&gt;&gt; On Wed, Apr 07, 2021 at 10:49:05AM -0500, B. Estrade wrote: <br/>&gt; &gt;&gt; &gt;&gt;&gt; <br/>&gt; &gt;&gt; &gt;&gt;&gt;&gt; Here&#39;s some food for thought. When was was the last time <br/>&gt; &gt;&gt; anyone had a <br/>&gt; &gt;&gt; &gt;&gt;&gt;&gt; serious discussion of introducing smp thread safety into the <br/>&gt; &gt;&gt; language? Or <br/>&gt; &gt;&gt; &gt;&gt;&gt;&gt; easy access to atomics? These are, IMO, 2 very important and <br/>&gt; &gt;&gt; serious things <br/>&gt; &gt;&gt; &gt;&gt;&gt; <br/>&gt; &gt;&gt; &gt;&gt;&gt; Retrofitting proper multicore concurrency to perl would imply <br/>&gt; &gt;&gt; that it&#39;s <br/>&gt; &gt;&gt; &gt;&gt;&gt; possible at all. <br/>&gt; &gt;&gt; &gt;&gt;&gt; <br/>&gt; &gt;&gt; &gt;&gt;&gt; None of the comparable C-based dynamic languages have done it <br/>&gt; &gt;&gt; (eg Python, <br/>&gt; &gt;&gt; &gt;&gt;&gt; Ruby) <br/>&gt; &gt;&gt; &gt; <br/>&gt; &gt;&gt; &gt; Both Python and Ruby are not a good place to learn on how <br/>&gt; &gt;&gt; multiprocessing happens. <br/>&gt; &gt;&gt; &gt; There is much better place to learn from - Julia. <br/>&gt; &gt;&gt; &gt; <br/>&gt; &gt;&gt; &gt; Julia made interesting approach: syntax highly inspired by <br/>&gt; &gt;&gt; Python, but correctly <br/>&gt; &gt;&gt; &gt; deals with multithreading. In a sense - this is much developed <br/>&gt; &gt;&gt; Python with all missing <br/>&gt; &gt;&gt; &gt; features added into completely different language. <br/>&gt; &gt;&gt; &gt; <br/>&gt; &gt;&gt; &gt; Very interesting approach, and I suppose this is about what perl <br/>&gt; &gt;&gt; community intended <br/>&gt; &gt;&gt; &gt; to implement when perl6 discussion have begun in 2000. <br/>&gt; &gt;&gt; &gt; <br/>&gt; &gt;&gt; &gt; <br/>&gt; &gt;&gt; &gt; <br/>&gt; &gt;&gt; &gt;&gt;&gt; Ruby&#39;s new experimental new threading is an actor model (I <br/>&gt; &gt;&gt; believe) CPython <br/>&gt; &gt;&gt; &gt;&gt;&gt; is dogged by the GIL (all the threads you like, but if you&#39;re <br/>&gt; &gt;&gt; CPU bound then <br/>&gt; &gt;&gt; &gt;&gt;&gt; you&#39;re making one core very toasty) The seem to be thinking <br/>&gt; &gt;&gt; about going <br/>&gt; &gt;&gt; &gt;&gt;&gt; multicore by doing something like ithreads (using pickle to <br/>&gt; &gt;&gt; pass data <br/>&gt; &gt;&gt; &gt;&gt;&gt; structures between MULITPLICITY-like interpreters) but that&#39;s <br/>&gt; &gt;&gt; likely going <br/>&gt; &gt;&gt; &gt;&gt;&gt; to be as good as ithreads. <br/>&gt; &gt;&gt; &gt; <br/>&gt; &gt;&gt; &gt; It appears that reference counting + threading results in <br/>&gt; &gt;&gt; considerable slow down <br/>&gt; &gt;&gt; &gt; and the solution to the problem is good GC. <br/>&gt; &gt;&gt; &gt; This was &quot;proved&quot; by GILectomy project, see any google video on <br/>&gt; &gt;&gt; this or this <br/>&gt; &gt;&gt; &gt; nice summary https://news.ycombinator.com/item?id=11842779 <br/>&gt; &gt;&gt; &gt; <br/>&gt; &gt;&gt; &gt; Perl history on threading (PERL5005THREADS and then ITHREADS <br/>&gt; &gt;&gt; where 1st was <br/>&gt; &gt;&gt; &gt; deprecated and removed while 2nd was recently deprecated) gives <br/>&gt; &gt;&gt; me think <br/>&gt; &gt;&gt; &gt; that no real multithreading/multicoring is actually possible on <br/>&gt; &gt;&gt; language level. <br/>&gt; &gt;&gt; &gt; Developing into that direction now is just wasting of time. <br/>&gt; &gt;&gt; &gt; <br/>&gt; &gt;&gt; &gt; &quot;async&quot; is another story, which is Javascript way, where basic JS <br/>&gt; &gt;&gt; engine V8 is single-threaded. <br/>&gt; &gt;&gt; &gt; <br/>&gt; &gt;&gt; &gt; <br/>&gt; &gt;&gt; <br/>&gt; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259766.html Fri, 09 Apr 2021 09:40:06 +0000 Re: on changing perl's behavior by Christian Walde On Thu, 08 Apr 2021 23:18:43 +0200, Todd Rinaldo &lt;toddr@cpanel.net&gt; wrote:<br/><br/>&gt; I would argue (though it&#39;s hard to search for &quot;format&quot; in the issues list) that being able to close 50+ cases would be nice if we could just say: &quot;Formats are removed. this issue is now irrelevant.&quot;<br/><br/>One more addendum here.<br/><br/>There&#39;s a way to make everyone happy.<br/><br/><br/><br/>Define `use 7;` and up as: &quot;doesn&#39;t provide format-related things&quot;.<br/><br/>Define missing `use $v;` or one with $v &lt; 7 as: &quot;provides format-related things as they were pre-7&quot;.<br/><br/><br/><br/>That way we don&#39;t step on any toes of format users, and Leonerd can create new syntax using format-danglies in v7+.<br/><br/>-- <br/>With regards,<br/>Christian Walde<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259765.html Fri, 09 Apr 2021 09:32:44 +0000 Re: on changing perl's behavior by Christian Walde On Fri, 09 Apr 2021 04:23:43 +0200, Ricardo Signes &lt;perl.p5p@rjbs.manxome.org&gt; wrote:<br/><br/>&gt; On Thu, Apr 8, 2021, at 5:18 PM, Todd Rinaldo wrote:<br/>&gt;&gt;&gt; Outside of that, when a huge win can be demonstrated, stuff should be removed, but &gt;&gt;&gt;then i&#39;d prefer it be done by way of deprecating that specific dialect.<br/>&gt;&gt;<br/>&gt;&gt; I would argue (though it&#39;s hard to search for &quot;format&quot; in the issues list) that being able to close 50+ &gt;&gt;cases would be nice if we could just say: &quot;Formats are removed. this issue is now irrelevant.&quot;<br/>&gt;<br/>&gt; I think that&#39;s true, strictly speaking, but: of the people who use formats, how many would be impacted, and how, if &gt;we removed formats? Well, 100% of them would be impacted, and the impact would be &quot;I had to rewrite some &gt;code&quot; which (given how formats work) would probably be kind of a pain in the butt. Sometimes a big one, &gt;sometimes pretty tiny.<br/>&gt;<br/>&gt; On the other hand, the benefit of closing tickets that we were ignoring anyway is pretty darn low.<br/>&gt;<br/>&gt; Christian&#39;s #2, changing defaults when they confound users, should be weighed against users confounded. I think &gt;we&#39;d find that in general, new users are not reaching for formats. If users say &quot;I&#39;m using formats, and this part was &gt;confusing,&quot; and we say, &quot;okay, we have ripped out formats,&quot; I don&#39;t think anybody&#39;s going to thank us for that.<br/><br/>100% agree with this, and to add a little more:<br/><br/>My first three points were for changed defaults.<br/><br/>&quot;remove behavior&quot; is a separate concern, as removing behavior only very rarely results in fixed bugs, but usually explicitly in WONTFIX.<br/><br/>-- <br/>With regards,<br/>Christian Walde https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259764.html Fri, 09 Apr 2021 08:34:10 +0000 Re: on changing perl's behavior by Christian Walde On Fri, 09 Apr 2021 10:07:31 +0200, Ovid via perl5-porters &lt;perl5-porters@perl.org&gt; wrote:<br/><br/>&gt; On Friday, 9 April 2021, 04:24:34 CEST, Ricardo Signes &lt;perl.p5p@rjbs.manxome.org&gt; wrote:<br/>&gt;<br/>&gt; On Thu, Apr 8, 2021, at 5:18 PM, Todd Rinaldo wrote:<br/>&gt;&gt;&gt; Outside of that, when a huge win can be demonstrated, stuff should be removed, &gt;&gt;&gt;but then i&#39;d prefer it be done by way of deprecating that specific dialect.<br/>&gt;&gt;<br/>&gt;&gt; Christian&#39;s #2, changing defaults when they confound users, should be weighed against users &gt;&gt;confounded. I think we&#39;d find that in general, new users are not reaching for formats. If users &gt;&gt;say &quot;I&#39;m using formats, and this part was confusing,&quot; and we say, &quot;okay, we have ripped out &gt;&gt;formats,&quot; I don&#39;t think anybody&#39;s going to thank us for that.<br/>&gt;<br/>&gt; Late to the party, not a core dev, and probably shouldn&#39;t wade into the lion&#39;s den, but I&#39;d like to offer my &gt;(obviously biased) thoughts.<br/>[...]<br/>&gt; So, given the assumption that Perl&#39;s push/pull ratio is poor, I contend that only a wholesale, radical upgrade &gt;of the language is the only way to save it.<br/><br/>Less of a den of lions matter it&#39;s a question of what was already discussed. :)<br/><br/>It sounds like you&#39;re agreeing with noises made previously, to cite myself here:<br/><br/> &quot;I want future Perls to be as bold as possible. I want Perl v7 to<br/> change as much as it humanly can. I want it to be brutal, a sledge<br/> hammer. I want it to include every possible default change we can<br/> remotely justify. I want it to change so much as to get close to<br/> being a new language as the major version bump indicates.&quot;<br/><br/>and to cite Leonerd:<br/><br/> We need to look at who is, and isn&#39;t, using Perl currently and<br/> consider whether actually `use VERSION` would help us provide a<br/> better Perl for both of these use-cases, as well as give us a<br/> great way to build a lot of marketing and promotion around that<br/> by pointing out that both kinds of Perl even exist.<br/><br/><br/>Source for both: https://www.nntp.perl.org/group/perl.perl5.porters/2021/03/msg259585.html<br/><br/><br/>-- <br/>With regards,<br/>Christian Walde https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259763.html Fri, 09 Apr 2021 08:26:04 +0000 Re: on changing perl's behavior by Ovid via perl5-porters On Friday, 9 April 2021, 04:24:34 CEST, Ricardo Signes &lt;perl.p5p@rjbs.manxome.org&gt; wrote: <br/> <br/> On Thu, Apr 8, 2021, at 5:18 PM, Todd Rinaldo wrote: <br/> <br/> <br/>Outside of that, when a huge win can be demonstrated, stuff should be removed, but then i&#39;d prefer it be done by way of deprecating that specific dialect. <br/> <br/> <br/>Christian&#39;s #2, changing defaults when they confound users, should be weighed against users confounded.&nbsp; I think we&#39;d find that in general, new users are not reaching for formats.&nbsp; If users say &quot;I&#39;m using formats, and this part was confusing,&quot; and we say, &quot;okay, we have ripped out formats,&quot; I don&#39;t think anybody&#39;s going to thank us for that. <br/> <br/>Late to the party, not a core dev, and probably shouldn&#39;t wade into the lion&#39;s den, but I&#39;d like to offer my (obviously biased) thoughts. <br/> <br/>I have read and written on the subject of emigration for many years and I having been thinking that those issues are relevant to Perl. Why do people leave a country? There are push factors (war, famine, lack of jobs, discrimination, etc.) and pull factors (climate, jobs, culture, etc.). When push factors are the primary motivation (think &quot;Somalia&quot;), refugees will flee to just about any place that will take them. When pull factors are the primary motivation, people want to go there. The US and France, for example, both have plenty of (very different) pull factors and lots of people want to move to those countries. <br/>It&#39;s even stronger for programming languages because there&#39;s not mcuh barrier to entry to other languages. <br/>Perl has a lot of push factors (fewer jobs, old-fashioned language, frequently cryptic syntax), but what are the pull factors? I don&#39;t mean the pull factors for us. We&#39;re not the target audience here. I mean &quot;pull factors for new developers.&quot; It&#39;s not the CPAN. It&#39;s not unicode support. PCRE is nice by most regexes I encounter in the wild aren&#39;t much more complicated than /ab(c*)de/. It&#39;s a nice glue language, but DevOps chose Ruby instead (why? push factors). <br/> <br/>I can name push factors for Perl all day long, but pull factors? And pull factors that overcome the push factors? And make Perl more enticing than alternative languages? I could start listing push/pull factors for Python, but I don&#39;t want to start the day silently weeping into my coffee. <br/> <br/>So, some points that I think are important: <br/> <br/> <br/> - If we break back-compat silently, people won&#39;t blame the sysadmin who upgraded without checking. They&#39;ll blame Perl. That&#39;s a new push factor. <br/> <br/> - I don&#39;t hear other devs saying I won&#39;t use Perl because of &lt;insert unpopular feature here&gt;. They say &quot;I won&#39;t use Perl because it&#39;s Perl.&quot; We could use this bullet point to list many, many push factors. <br/> <br/> - Perl will die unless we give people a reason to try it again (and I agree that new OOP isn&#39;t the solution, but I contend that it&#39;s part of it). We need lots of pull factors. <br/> <br/> <br/>Saying we should just keep Perl as &quot;Perl&quot;, maybe remove some cruft is ignoring pull factors. It&#39;s saying &quot;I want to go gentle into that good night.&quot; Perl will continue it&#39;s long slide into irrelevancy and people who enjoy Perl will have to find other ways of paying the bills. Make developers sit up and say &quot;I want that!&quot; When I give intro Raku talks, developers sit up and say &quot;I want that.!&quot; They say that about numerous features. They don&#39;t say that about Perl. (That&#39;s not saying anything about whether or not Raku will be successful) <br/>So, given the assumption that Perl&#39;s push/pull ratio is poor, I contend that only a wholesale, radical upgrade of the language is the only way to save it. <br/> <br/>Best,Ovid <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259762.html Fri, 09 Apr 2021 08:07:42 +0000 by B. Estrade <br/><br/>On 4/9/21 2:26 AM, Eric Wong wrote:<br/>&gt; &quot;B. Estrade&quot; &lt;brett@cpanel.net&gt; wrote:<br/>&gt;&gt; 0. &#39;_r&#39; indicates &quot;thread safe&quot; - this is an old tradition from IBM; google<br/>&gt;&gt; it, it&#39;s a thing; I promise.<br/>&gt; <br/>&gt; AFAIK it initially meant &quot;reentrant&quot; (as in safe functions<br/>&gt; inside C sig handlers). Thread-safety and reentrancy can<br/>&gt; overlap sometimes, but not always. Some implementers<br/>&gt; unfortunately propagated the confusion by naming<br/>&gt; non-reentrant-but-thread-safe things &quot;_r&quot;.<br/>&gt; <br/>&gt;&gt; 4. thread safe analogs to things like printf (see inline comment in code<br/>&gt;&gt; above)<br/>&gt; <br/>&gt; Perl buffered I/O might be better off being thread-safe by<br/>&gt; default to mimic C stdio characteristics. It would reduce the<br/>&gt; learning curve and reduce confusion for users switching between<br/>&gt; C and Perl. Note that C printf is not reentrant, since it uses<br/>&gt; locking under-the-hood, but Perl printf is due to &quot;safe signals&quot;.<br/>&gt; <br/><br/>Fair points, and thank you for the clarification.<br/><br/>Brett<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259761.html Fri, 09 Apr 2021 07:40:27 +0000 =?UTF-8?Q?p5_fan_fiction_=28was_Re=3a_threads_and_stuff_=28was_Re?==?UTF-8?B?OiBQZXJs4oCZcyBsZWFreSBidWNrZXQpKQ==?= by B. Estrade Even when I make up the rules, I still write terrible code in a rush.<br/><br/>https://github.com/oodler577/p5-fan-fiction/blob/master/01/01-hello.pl<br/>https://github.com/oodler577/p5-fan-fiction/blob/master/01/02-bakery.pl<br/><br/>And I figured, why should I have all the fun. If anyone is so inclined, <br/>follow the writing prompt and proceed. Remember, this is all pretend. I <br/>did clean up my off the cuff examples as best as I could...<br/><br/>Challenge 01 (of possibly 1) - how would you write &quot;threaded&quot; perl [see <br/>writing prompt]?<br/><br/>https://github.com/oodler577/p5-fan-fiction/blob/master/01/00-PROMPT.pod<br/><br/>Enjoy.<br/><br/>Brett<br/><br/>On 4/9/21 12:53 AM, B. Estrade wrote:<br/>&gt; <br/>&gt; <br/>&gt; On 4/8/21 11:50 PM, Yuki Kimoto wrote:<br/>&gt;&gt; B. Estrade<br/>&gt;&gt;<br/>&gt;&gt; I don&#39;t yet understand what you want.<br/>&gt; <br/>&gt; You and me both. What I *want* and what I think we have to do to get <br/>&gt; there are two vastly different things.<br/>&gt; <br/>&gt; For now, I want all of us to think &quot;thread safety&quot; and &quot;SMP&quot; in <br/>&gt; everything we do. Not in a design sense, in the unconsiousness sense; so <br/>&gt; it imbues itself in every aspect of any work and thinking done in the <br/>&gt; name of perl/Perl.<br/>&gt; <br/>&gt; If you ask me right now; in 2024, I&#39;d like to be able to do something as <br/>&gt; simple as this as a single OS process, but utilizing &quot;light weight&quot; OS <br/>&gt; threads (e.g., pthreads):<br/>&gt; <br/>&gt; &nbsp; #!/usr/bin/env perl<br/>&gt; &nbsp; use strict;<br/>&gt; &nbsp; use warnings;<br/>&gt; &nbsp; use v12;<br/>&gt; <br/>&gt; &nbsp; # &#39;traditional perl code&#39;<br/>&gt; &nbsp; #...<br/>&gt; &nbsp; #<br/>&gt; <br/>&gt; &nbsp; my_r $mailbox_rref = [];<br/>&gt; &nbsp; map_r(8) {<br/>&gt; &nbsp;&nbsp;&nbsp; local $thread_id = tid();<br/>&gt; &nbsp;&nbsp;&nbsp; $mailbox_rref-&gt;[$thread_id] = qq{Hello from thread #$thread_id};<br/>&gt; &nbsp; }<br/>&gt; &nbsp; foreach my $msg (@$mailbox_ref) {<br/>&gt; &nbsp;&nbsp;&nbsp; say $msg;<br/>&gt; &nbsp; }<br/>&gt; <br/>&gt; Output:<br/>&gt; <br/>&gt; Hello from thread # 0<br/>&gt; Hello from thread # 1<br/>&gt; Hello from thread # 2<br/>&gt; Hello from thread # 3<br/>&gt; Hello from thread # 4<br/>&gt; Hello from thread # 5<br/>&gt; Hello from thread # 6<br/>&gt; Hello from thread # 7<br/>&gt; <br/>&gt; Another example,<br/>&gt; <br/>&gt; &nbsp; #!/usr/bin/env perl<br/>&gt; &nbsp; use strict;<br/>&gt; &nbsp; use warnings;<br/>&gt; &nbsp; use v12;<br/>&gt; <br/>&gt; &nbsp; # &#39;traditional perl code&#39;<br/>&gt; &nbsp; #...<br/>&gt; &nbsp; #<br/>&gt; <br/>&gt; &nbsp; sub state_var_update {<br/>&gt; &nbsp;&nbsp;&nbsp; state $ret = 0;<br/>&gt; &nbsp;&nbsp;&nbsp; return ++$ret;<br/>&gt; &nbsp; }<br/>&gt; <br/>&gt; &nbsp; sub atomic_var_update {<br/>&gt; &nbsp;&nbsp;&nbsp; atomic $ret = 0;&nbsp;&nbsp; # like &#39;state&#39; but actions upon it are atomic<br/>&gt; &nbsp;&nbsp;&nbsp; return ++$ret;&nbsp;&nbsp;&nbsp;&nbsp; # atomic nature forces unordered serialization<br/>&gt; &nbsp; }<br/>&gt; <br/>&gt; &nbsp; sub now_serving {<br/>&gt; &nbsp;&nbsp;&nbsp; state $now_serving = 0;<br/>&gt; &nbsp;&nbsp;&nbsp; my $ticket = shift;<br/>&gt; &nbsp;&nbsp;&nbsp; return undef if $ticket != $now_serving;<br/>&gt; &nbsp;&nbsp;&nbsp; return q{You&#39;ve been served a nice warm rye loaf!};<br/>&gt; &nbsp; }<br/>&gt; <br/>&gt; &nbsp; my $num_threads = 8;<br/>&gt; &nbsp; map_r($num_threads) {<br/>&gt; &nbsp;&nbsp;&nbsp; local $thread_id = tid();<br/>&gt; &nbsp;&nbsp;&nbsp; local $bakery_ticket = atomic_var_update; # threads race<br/>&gt; &nbsp;&nbsp;&nbsp; # threads do stuff<br/>&gt; &nbsp;&nbsp;&nbsp; # .. and more stuff<br/>&gt; &nbsp;&nbsp;&nbsp; # ... and maybe more stuff<br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; # busy wait<br/>&gt; &nbsp;&nbsp;&nbsp; do {<br/>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; local $ihazbeenserved = now_serving($bakery_ticket);<br/>&gt; &nbsp;&nbsp;&nbsp; } while(not $ihazbeenserved);<br/>&gt; <br/>&gt; &nbsp;&nbsp;&nbsp; # &quot;safely&quot; print to STDOUT without clobbering (could use regular<br/>&gt; &nbsp;&nbsp;&nbsp; # printf and risk messages overlapping)<br/>&gt; &nbsp;&nbsp;&nbsp; printf_r(&quot;Yay! I, thread %d, now has my %s&quot;, $tid, $ihazbeenserved);<br/>&gt; &nbsp; }<br/>&gt; <br/>&gt; &nbsp; # had to google for the following<br/>&gt; &nbsp; format STUDENT =<br/>&gt; &nbsp; ===================================<br/>&gt; &nbsp; @&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; @&lt;&lt;<br/>&gt; &nbsp; $name $age<br/>&gt; &nbsp; @#####.##<br/>&gt; &nbsp; $fee<br/>&gt; &nbsp; ===================================<br/>&gt; &nbsp; .<br/>&gt; <br/>&gt; &nbsp; select(STDOUT);<br/>&gt; &nbsp; $~ = STUDENT;<br/>&gt; <br/>&gt; &nbsp; @n = (&quot;Deepak&quot;, &quot;Rajat&quot;, &quot;Vikrant&quot;);<br/>&gt; &nbsp; @a&nbsp; = (18, 16, 14);<br/>&gt; &nbsp; @s = (2000.00, 2500.00, 4000.000);<br/>&gt; <br/>&gt; &nbsp; $i = 0;<br/>&gt; &nbsp; foreach (@n)<br/>&gt; &nbsp; {<br/>&gt; &nbsp;&nbsp;&nbsp;&nbsp; $name = $_;<br/>&gt; &nbsp;&nbsp;&nbsp;&nbsp; $age = $a[$i];<br/>&gt; &nbsp;&nbsp;&nbsp;&nbsp; $fee = $s[$i++];<br/>&gt; &nbsp;&nbsp;&nbsp;&nbsp; write;<br/>&gt; &nbsp; }<br/>&gt; <br/>&gt;&gt;<br/>&gt;&gt; If you want to call OpenMP easily, I&#39;m also trying in my SPVM module.<br/>&gt;&gt;<br/>&gt;&gt; https://github.com/yuki-kimoto/SPVM/tree/master/examples/native/openmp<br/>&gt;&gt;<br/>&gt; <br/>&gt; I saw your module come through on metacpan under &quot;recent&quot; and it looked <br/>&gt; very interesting. I&#39;ll look deeper into it.<br/>&gt; <br/>&gt;&gt; Perl already has Inline::C/XS/FFIs modules. SPVM is another way to <br/>&gt;&gt; bind C libraries.<br/>&gt;&gt;<br/>&gt;&gt; More example<br/>&gt;&gt;<br/>&gt;&gt; -cuda<br/>&gt;&gt; -Eigen<br/>&gt;&gt; -GSL<br/>&gt;&gt; -OpenCV<br/>&gt;&gt; -zlib<br/>&gt;&gt;<br/>&gt;&gt; https://github.com/yuki-kimoto/SPVM/tree/master/examples/native<br/>&gt; <br/>&gt; Yes, very nice. I will look at it. Whereas what I want and what I am <br/>&gt; playing with are vastly different, I am also very interested in FFI type <br/>&gt; support for leveraging SMP, GPUs (not really myself but it&#39;s important), <br/>&gt; etc.<br/>&gt; <br/>&gt; My two examples above point to a few things:<br/>&gt; <br/>&gt; 0. &#39;_r&#39; indicates &quot;thread safe&quot; - this is an old tradition from IBM; <br/>&gt; google it, it&#39;s a thing; I promise.<br/>&gt; <br/>&gt; 1. atomic data types (thread safe) that in addition to providing for <br/>&gt; &quot;safe&quot; updates (one thread at a time), can serve as barriers <br/>&gt; (serialization points)<br/>&gt; <br/>&gt; 2. a map_r (or similar) construct that provides a threaded environment; <br/>&gt; yes, I know &#39;map_r&#39; also implies a lot of things related to the existing <br/>&gt; &#39;map&#39;; that&#39;d be cool to, but it seemed like a more apt name that what I <br/>&gt; had originally, &#39;fork_r&#39;.<br/>&gt; <br/>&gt; 3. ability for threads to call all subs &quot;unsafely&quot; (race condition); but <br/>&gt; with the judicious use of atomics can provide barriers to keep things<br/>&gt; <br/>&gt; 4. thread safe analogs to things like printf (see inline comment in code <br/>&gt; above)<br/>&gt; <br/>&gt; 5. the use of &#39;format&#39; was just because I&#39;ve never used it before and <br/>&gt; had just googled it to see what it&#39;s all about :)<br/>&gt; <br/>&gt; I quite enjoyed coming up these examples, and I might even as an <br/>&gt; exercise try to come up with many more so that when asked - &quot;what do you <br/>&gt; mean&quot; or &quot;show me an example&quot; of what you are thinking, I can point to <br/>&gt; that.<br/>&gt; <br/>&gt; Even after this thought exercise, I am beginning to see how a mix of the <br/>&gt; following might point us in the right direction (and through the <br/>&gt; minefield that is the perl runtime):<br/>&gt; <br/>&gt; * a threaded block (above it&#39;s map_r, could be fork_r, or just spawner, <br/>&gt; etc)<br/>&gt; * thread safe forms of:<br/>&gt; &nbsp; - scalar reference; declared with &#39;my_r&#39;, array ref or hash ref on <br/>&gt; the other end is assumed to be a &#39;thread safe&#39; anonymous array or hash<br/>&gt; &nbsp; - arrays - slots can be updated in a threaded environment (threads <br/>&gt; can be unsafe and simultaneously update an element; but that&#39;s the risk <br/>&gt; with SMP)<br/>&gt; &nbsp; - hash - same concept as &#39;thread safe&#39; array, but hash<br/>&gt; &nbsp; - atomic - an actual scalar value that can be safely updated; it&#39;s <br/>&gt; primary use is as a synchronization point; default access is &quot;unordered&quot; <br/>&gt; meaning first thread there wins, then all others line up <br/>&gt; non-deterministically; there should probably be an way to &#39;order&#39; <br/>&gt; threads based on tid() in some efficient way<br/>&gt; <br/>&gt; Other thoughts,<br/>&gt; <br/>&gt; * sub_r: thread safe form of &#39;sub&#39; that has a serialization effect as <br/>&gt; well, except it is run by only one thread at a time (user is allowed to <br/>&gt; do unsafe things using perl&#39;s traditional scoping rules) - akin to an <br/>&gt; OpenMP &#39;critical&#39; section.<br/>&gt; <br/>&gt; Anyway, thanks for asking. I&#39;ll think more about it and see if I can <br/>&gt; flesh it out more.<br/>&gt; <br/>&gt; Note, I am not going for any particular concurrency model. I am going <br/>&gt; for &quot;what does SMP look like in perl5&quot;. I think I have a good idea, and <br/>&gt; the &#39;_r&#39; stuff and atomic(s) are merely language additions to get around <br/>&gt; affecting &quot;serial&quot; perl. (no I don&#39;t want a perl_r; just for the record).<br/>&gt; <br/>&gt; Brett<br/>&gt; <br/>&gt;&gt;<br/>&gt;&gt; 2021&#x5E74;4&#x6708;9&#x65E5;(&#x91D1;) 0:05 B. Estrade &lt;brett@cpanel.net <br/>&gt;&gt; &lt;mailto:brett@cpanel.net&gt;&gt;:<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; Thank you, appreciate the reply. To avoid collision with the other<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; thread, I update the subject.<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; So I suppose this cuts to the heart of the matter. It&#39;s fair, I<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; believe,<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; that &quot;top level &#39;threading&#39;&quot; is not something that can be reasonable<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; supported in the perl runtime (and to be fair, other scripting<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; languages<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; also struggle greatly with this).<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; The question, then goes to: how do we facilitate access to the native<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; platform&#39;s SMP? Perhaps the answer is, as always, &quot;it depends.&quot;<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; I will continue to pound my head on this, something will shake<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; loose. In<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; the meantime, as proof that I am vested in seeing some interesting<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; options shake loose, I have offered a module on CPAN called<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; OpenMP::Environment.<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; It only provides programmatic manipulation of the environmental<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; variables that OpenMP programs care about; but it is a necessary step<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; for me to investigate and gain some intuition about what is possible<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; and<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; what looks &quot;right&quot;.<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; Currently I am thinking a SIMD (single instruction, multiple data)<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; approach is the most accessible. This doesn&#39;t really get at what is<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; ideal (in my mind), but at least provides a path forward by creating<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; threaded libraries made available via Inline::C/XS/FFIs - and even<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; leveraging these via a tie interface. And if the direction of <br/>&gt;&gt; providing<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; SIMD &quot;data types&quot; is truly the best direction, PDL seems like a <br/>&gt;&gt; really<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; good target for that.<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; Thanks for all the feedback, will monitor the list/thread. I do ask<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; that<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; we keep the whole idea of threading &quot;where and when feasible&quot; <br/>&gt;&gt; (even in<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; language design considerations) is extremely important to Perl&#39;s long<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; term viability and as a driver of important capabilities. The idea of<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; using Perl to efficiently max out a large SMP machine for useful<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; work is<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; very exciting to me, and I think I am not the only one.<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; Cheers,<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; Brett<br/>&gt;&gt;<br/>&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; On 4/8/21 3:42 AM, Konovalov, Vadim wrote:<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt; Nicholas Clark &lt;nick@ccl4.org &lt;mailto:nick@ccl4.org&gt;&gt; wrote:<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; On Wed, Apr 07, 2021 at 10:49:05AM -0500, B. Estrade wrote:<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt;&gt; Here&#39;s some food for thought. When was was the last time<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; anyone had a<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt;&gt; serious discussion of introducing smp thread safety into the<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; language? Or<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt;&gt; easy access to atomics? These are, IMO, 2 very important and<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; serious things<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; Retrofitting proper multicore concurrency to perl would imply<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; that it&#39;s<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; possible at all.<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; None of the comparable C-based dynamic languages have done it<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; (eg Python,<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; Ruby)<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; Both Python and Ruby are not a good place to learn on how<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; multiprocessing happens.<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; There is much better place to learn from - Julia.<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; Julia made interesting approach: syntax highly inspired by<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; Python, but correctly<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; deals with multithreading. In a sense - this is much developed<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; Python with all missing<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; features added into completely different language.<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; Very interesting approach, and I suppose this is about what perl<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; community intended<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; to implement when perl6 discussion have begun in 2000.<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; Ruby&#39;s new experimental new threading is an actor model (I<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; believe) CPython<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; is dogged by the GIL (all the threads you like, but if you&#39;re<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; CPU bound then<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; you&#39;re making one core very toasty) The seem to be thinking<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; about going<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; multicore by doing something like ithreads (using pickle to<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; pass data<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; structures between MULITPLICITY-like interpreters) but that&#39;s<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; likely going<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;&gt;&gt; to be as good as ithreads.<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; It appears that reference counting + threading results in<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; considerable slow down<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; and the solution to the problem is good GC.<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; This was &quot;proved&quot; by GILectomy project, see any google video on<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; this or this<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; nice summary https://news.ycombinator.com/item?id=11842779<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; Perl history on threading (PERL5005THREADS and then ITHREADS<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; where 1st was<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; deprecated and removed while 2nd was recently deprecated) gives<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; me think<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; that no real multithreading/multicoring is actually possible on<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; language level.<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; Developing into that direction now is just wasting of time.<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt; &quot;async&quot; is another story, which is Javascript way, where basic JS<br/>&gt;&gt; &nbsp;&nbsp;&nbsp; engine V8 is single-threaded.<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;<br/>&gt;&gt; &nbsp;&nbsp;&nbsp;&nbsp; &gt;<br/>&gt;&gt;<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259760.html Fri, 09 Apr 2021 07:26:14 +0000 Re: threads and stuff (was Re: =?utf-8?Q?P?==?utf-8?B?ZXJs4oCZcw==?= leaky bucket) by Eric Wong &quot;B. Estrade&quot; &lt;brett@cpanel.net&gt; wrote:<br/>&gt; 0. &#39;_r&#39; indicates &quot;thread safe&quot; - this is an old tradition from IBM; google<br/>&gt; it, it&#39;s a thing; I promise.<br/><br/>AFAIK it initially meant &quot;reentrant&quot; (as in safe functions<br/>inside C sig handlers). Thread-safety and reentrancy can<br/>overlap sometimes, but not always. Some implementers<br/>unfortunately propagated the confusion by naming<br/>non-reentrant-but-thread-safe things &quot;_r&quot;.<br/><br/>&gt; 4. thread safe analogs to things like printf (see inline comment in code<br/>&gt; above)<br/><br/>Perl buffered I/O might be better off being thread-safe by<br/>default to mimic C stdio characteristics. It would reduce the<br/>learning curve and reduce confusion for users switching between<br/>C and Perl. Note that C printf is not reentrant, since it uses<br/>locking under-the-hood, but Perl printf is due to &quot;safe signals&quot;.<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259759.html Fri, 09 Apr 2021 07:26:08 +0000 by Dan Book On Fri, Apr 9, 2021 at 1:54 AM B. Estrade &lt;brett@cpanel.net&gt; wrote:<br/><br/>&gt;<br/>&gt; 2. a map_r (or similar) construct that provides a threaded environment;<br/>&gt; yes, I know &#39;map_r&#39; also implies a lot of things related to the existing<br/>&gt; &#39;map&#39;; that&#39;d be cool to, but it seemed like a more apt name that what I<br/>&gt; had originally, &#39;fork_r&#39;.<br/>&gt;<br/><br/>It&#39;s still based on our current forking and event loop stuff, but I just<br/>wanted to mention this nice (though underdocumented) interface:<br/>https://metacpan.org/pod/Parallel::Map (essentially Future::Utils::fmap +<br/>IO::Async::Function)<br/><br/>-Dan<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259758.html Fri, 09 Apr 2021 06:19:11 +0000 by B. Estrade <br/><br/>On 4/8/21 11:50 PM, Yuki Kimoto wrote:<br/>&gt; B. Estrade<br/>&gt; <br/>&gt; I don&#39;t yet understand what you want.<br/><br/>You and me both. What I *want* and what I think we have to do to get <br/>there are two vastly different things.<br/><br/>For now, I want all of us to think &quot;thread safety&quot; and &quot;SMP&quot; in <br/>everything we do. Not in a design sense, in the unconsiousness sense; so <br/>it imbues itself in every aspect of any work and thinking done in the <br/>name of perl/Perl.<br/><br/>If you ask me right now; in 2024, I&#39;d like to be able to do something as <br/>simple as this as a single OS process, but utilizing &quot;light weight&quot; OS <br/>threads (e.g., pthreads):<br/><br/> #!/usr/bin/env perl<br/> use strict;<br/> use warnings;<br/> use v12;<br/><br/> # &#39;traditional perl code&#39;<br/> #...<br/> #<br/><br/> my_r $mailbox_rref = [];<br/> map_r(8) {<br/> local $thread_id = tid();<br/> $mailbox_rref-&gt;[$thread_id] = qq{Hello from thread #$thread_id};<br/> }<br/> foreach my $msg (@$mailbox_ref) {<br/> say $msg;<br/> }<br/><br/>Output:<br/><br/>Hello from thread # 0<br/>Hello from thread # 1<br/>Hello from thread # 2<br/>Hello from thread # 3<br/>Hello from thread # 4<br/>Hello from thread # 5<br/>Hello from thread # 6<br/>Hello from thread # 7<br/><br/>Another example,<br/><br/> #!/usr/bin/env perl<br/> use strict;<br/> use warnings;<br/> use v12;<br/><br/> # &#39;traditional perl code&#39;<br/> #...<br/> #<br/><br/> sub state_var_update {<br/> state $ret = 0;<br/> return ++$ret;<br/> }<br/><br/> sub atomic_var_update {<br/> atomic $ret = 0; # like &#39;state&#39; but actions upon it are atomic<br/> return ++$ret; # atomic nature forces unordered serialization<br/> }<br/><br/> sub now_serving {<br/> state $now_serving = 0;<br/> my $ticket = shift;<br/> return undef if $ticket != $now_serving;<br/> return q{You&#39;ve been served a nice warm rye loaf!};<br/> }<br/><br/> my $num_threads = 8;<br/> map_r($num_threads) {<br/> local $thread_id = tid();<br/> local $bakery_ticket = atomic_var_update; # threads race<br/> # threads do stuff<br/> # .. and more stuff<br/> # ... and maybe more stuff<br/><br/> # busy wait<br/> do {<br/> local $ihazbeenserved = now_serving($bakery_ticket);<br/> } while(not $ihazbeenserved);<br/><br/> # &quot;safely&quot; print to STDOUT without clobbering (could use regular<br/> # printf and risk messages overlapping)<br/> printf_r(&quot;Yay! I, thread %d, now has my %s&quot;, $tid, $ihazbeenserved);<br/> }<br/><br/> # had to google for the following<br/> format STUDENT =<br/> ===================================<br/> @&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; @&lt;&lt;<br/> $name $age<br/> @#####.##<br/> $fee<br/> ===================================<br/> .<br/><br/> select(STDOUT);<br/> $~ = STUDENT;<br/><br/> @n = (&quot;Deepak&quot;, &quot;Rajat&quot;, &quot;Vikrant&quot;);<br/> @a = (18, 16, 14);<br/> @s = (2000.00, 2500.00, 4000.000);<br/><br/> $i = 0;<br/> foreach (@n)<br/> {<br/> $name = $_;<br/> $age = $a[$i];<br/> $fee = $s[$i++];<br/> write;<br/> }<br/><br/>&gt; <br/>&gt; If you want to call OpenMP easily, I&#39;m also trying in my SPVM module.<br/>&gt; <br/>&gt; https://github.com/yuki-kimoto/SPVM/tree/master/examples/native/openmp<br/>&gt; <br/><br/>I saw your module come through on metacpan under &quot;recent&quot; and it looked <br/>very interesting. I&#39;ll look deeper into it.<br/><br/>&gt; Perl already has Inline::C/XS/FFIs modules. SPVM is another way to bind <br/>&gt; C libraries.<br/>&gt; <br/>&gt; More example<br/>&gt; <br/>&gt; -cuda<br/>&gt; -Eigen<br/>&gt; -GSL<br/>&gt; -OpenCV<br/>&gt; -zlib<br/>&gt; <br/>&gt; https://github.com/yuki-kimoto/SPVM/tree/master/examples/native<br/><br/>Yes, very nice. I will look at it. Whereas what I want and what I am <br/>playing with are vastly different, I am also very interested in FFI type <br/>support for leveraging SMP, GPUs (not really myself but it&#39;s important), <br/>etc.<br/><br/>My two examples above point to a few things:<br/><br/>0. &#39;_r&#39; indicates &quot;thread safe&quot; - this is an old tradition from IBM; <br/>google it, it&#39;s a thing; I promise.<br/><br/>1. atomic data types (thread safe) that in addition to providing for <br/>&quot;safe&quot; updates (one thread at a time), can serve as barriers <br/>(serialization points)<br/><br/>2. a map_r (or similar) construct that provides a threaded environment; <br/>yes, I know &#39;map_r&#39; also implies a lot of things related to the existing <br/>&#39;map&#39;; that&#39;d be cool to, but it seemed like a more apt name that what I <br/>had originally, &#39;fork_r&#39;.<br/><br/>3. ability for threads to call all subs &quot;unsafely&quot; (race condition); but <br/>with the judicious use of atomics can provide barriers to keep things<br/><br/>4. thread safe analogs to things like printf (see inline comment in code <br/>above)<br/><br/>5. the use of &#39;format&#39; was just because I&#39;ve never used it before and <br/>had just googled it to see what it&#39;s all about :)<br/><br/>I quite enjoyed coming up these examples, and I might even as an <br/>exercise try to come up with many more so that when asked - &quot;what do you <br/>mean&quot; or &quot;show me an example&quot; of what you are thinking, I can point to that.<br/><br/>Even after this thought exercise, I am beginning to see how a mix of the <br/>following might point us in the right direction (and through the <br/>minefield that is the perl runtime):<br/><br/>* a threaded block (above it&#39;s map_r, could be fork_r, or just spawner, etc)<br/>* thread safe forms of:<br/> - scalar reference; declared with &#39;my_r&#39;, array ref or hash ref on <br/>the other end is assumed to be a &#39;thread safe&#39; anonymous array or hash<br/> - arrays - slots can be updated in a threaded environment (threads <br/>can be unsafe and simultaneously update an element; but that&#39;s the risk <br/>with SMP)<br/> - hash - same concept as &#39;thread safe&#39; array, but hash<br/> - atomic - an actual scalar value that can be safely updated; it&#39;s <br/>primary use is as a synchronization point; default access is &quot;unordered&quot; <br/>meaning first thread there wins, then all others line up <br/>non-deterministically; there should probably be an way to &#39;order&#39; <br/>threads based on tid() in some efficient way<br/><br/>Other thoughts,<br/><br/>* sub_r: thread safe form of &#39;sub&#39; that has a serialization effect as <br/>well, except it is run by only one thread at a time (user is allowed to <br/>do unsafe things using perl&#39;s traditional scoping rules) - akin to an <br/>OpenMP &#39;critical&#39; section.<br/><br/>Anyway, thanks for asking. I&#39;ll think more about it and see if I can <br/>flesh it out more.<br/><br/>Note, I am not going for any particular concurrency model. I am going <br/>for &quot;what does SMP look like in perl5&quot;. I think I have a good idea, and <br/>the &#39;_r&#39; stuff and atomic(s) are merely language additions to get around <br/>affecting &quot;serial&quot; perl. (no I don&#39;t want a perl_r; just for the record).<br/><br/>Brett<br/><br/>&gt; <br/>&gt; 2021&#x5E74;4&#x6708;9&#x65E5;(&#x91D1;) 0:05 B. Estrade &lt;brett@cpanel.net <br/>&gt; &lt;mailto:brett@cpanel.net&gt;&gt;:<br/>&gt; <br/>&gt; Thank you, appreciate the reply. To avoid collision with the other<br/>&gt; thread, I update the subject.<br/>&gt; <br/>&gt; So I suppose this cuts to the heart of the matter. It&#39;s fair, I<br/>&gt; believe,<br/>&gt; that &quot;top level &#39;threading&#39;&quot; is not something that can be reasonable<br/>&gt; supported in the perl runtime (and to be fair, other scripting<br/>&gt; languages<br/>&gt; also struggle greatly with this).<br/>&gt; <br/>&gt; The question, then goes to: how do we facilitate access to the native<br/>&gt; platform&#39;s SMP? Perhaps the answer is, as always, &quot;it depends.&quot;<br/>&gt; <br/>&gt; I will continue to pound my head on this, something will shake<br/>&gt; loose. In<br/>&gt; the meantime, as proof that I am vested in seeing some interesting<br/>&gt; options shake loose, I have offered a module on CPAN called<br/>&gt; OpenMP::Environment.<br/>&gt; <br/>&gt; It only provides programmatic manipulation of the environmental<br/>&gt; variables that OpenMP programs care about; but it is a necessary step<br/>&gt; for me to investigate and gain some intuition about what is possible<br/>&gt; and<br/>&gt; what looks &quot;right&quot;.<br/>&gt; <br/>&gt; Currently I am thinking a SIMD (single instruction, multiple data)<br/>&gt; approach is the most accessible. This doesn&#39;t really get at what is<br/>&gt; ideal (in my mind), but at least provides a path forward by creating<br/>&gt; threaded libraries made available via Inline::C/XS/FFIs - and even<br/>&gt; leveraging these via a tie interface. And if the direction of providing<br/>&gt; SIMD &quot;data types&quot; is truly the best direction, PDL seems like a really<br/>&gt; good target for that.<br/>&gt; <br/>&gt; Thanks for all the feedback, will monitor the list/thread. I do ask<br/>&gt; that<br/>&gt; we keep the whole idea of threading &quot;where and when feasible&quot; (even in<br/>&gt; language design considerations) is extremely important to Perl&#39;s long<br/>&gt; term viability and as a driver of important capabilities. The idea of<br/>&gt; using Perl to efficiently max out a large SMP machine for useful<br/>&gt; work is<br/>&gt; very exciting to me, and I think I am not the only one.<br/>&gt; <br/>&gt; Cheers,<br/>&gt; Brett<br/>&gt; <br/>&gt; <br/>&gt; On 4/8/21 3:42 AM, Konovalov, Vadim wrote:<br/>&gt; &gt;&gt; Nicholas Clark &lt;nick@ccl4.org &lt;mailto:nick@ccl4.org&gt;&gt; wrote:<br/>&gt; &gt;&gt;&gt; On Wed, Apr 07, 2021 at 10:49:05AM -0500, B. Estrade wrote:<br/>&gt; &gt;&gt;&gt;<br/>&gt; &gt;&gt;&gt;&gt; Here&#39;s some food for thought. When was was the last time<br/>&gt; anyone had a<br/>&gt; &gt;&gt;&gt;&gt; serious discussion of introducing smp thread safety into the<br/>&gt; language? Or<br/>&gt; &gt;&gt;&gt;&gt; easy access to atomics? These are, IMO, 2 very important and<br/>&gt; serious things<br/>&gt; &gt;&gt;&gt;<br/>&gt; &gt;&gt;&gt; Retrofitting proper multicore concurrency to perl would imply<br/>&gt; that it&#39;s<br/>&gt; &gt;&gt;&gt; possible at all.<br/>&gt; &gt;&gt;&gt;<br/>&gt; &gt;&gt;&gt; None of the comparable C-based dynamic languages have done it<br/>&gt; (eg Python,<br/>&gt; &gt;&gt;&gt; Ruby)<br/>&gt; &gt;<br/>&gt; &gt; Both Python and Ruby are not a good place to learn on how<br/>&gt; multiprocessing happens.<br/>&gt; &gt; There is much better place to learn from - Julia.<br/>&gt; &gt;<br/>&gt; &gt; Julia made interesting approach: syntax highly inspired by<br/>&gt; Python, but correctly<br/>&gt; &gt; deals with multithreading. In a sense - this is much developed<br/>&gt; Python with all missing<br/>&gt; &gt; features added into completely different language.<br/>&gt; &gt;<br/>&gt; &gt; Very interesting approach, and I suppose this is about what perl<br/>&gt; community intended<br/>&gt; &gt; to implement when perl6 discussion have begun in 2000.<br/>&gt; &gt;<br/>&gt; &gt;<br/>&gt; &gt;<br/>&gt; &gt;&gt;&gt; Ruby&#39;s new experimental new threading is an actor model (I<br/>&gt; believe) CPython<br/>&gt; &gt;&gt;&gt; is dogged by the GIL (all the threads you like, but if you&#39;re<br/>&gt; CPU bound then<br/>&gt; &gt;&gt;&gt; you&#39;re making one core very toasty) The seem to be thinking<br/>&gt; about going<br/>&gt; &gt;&gt;&gt; multicore by doing something like ithreads (using pickle to<br/>&gt; pass data<br/>&gt; &gt;&gt;&gt; structures between MULITPLICITY-like interpreters) but that&#39;s<br/>&gt; likely going<br/>&gt; &gt;&gt;&gt; to be as good as ithreads.<br/>&gt; &gt;<br/>&gt; &gt; It appears that reference counting + threading results in<br/>&gt; considerable slow down<br/>&gt; &gt; and the solution to the problem is good GC.<br/>&gt; &gt; This was &quot;proved&quot; by GILectomy project, see any google video on<br/>&gt; this or this<br/>&gt; &gt; nice summary https://news.ycombinator.com/item?id=11842779<br/>&gt; &gt;<br/>&gt; &gt; Perl history on threading (PERL5005THREADS and then ITHREADS<br/>&gt; where 1st was<br/>&gt; &gt; deprecated and removed while 2nd was recently deprecated) gives<br/>&gt; me think<br/>&gt; &gt; that no real multithreading/multicoring is actually possible on<br/>&gt; language level.<br/>&gt; &gt; Developing into that direction now is just wasting of time.<br/>&gt; &gt;<br/>&gt; &gt; &quot;async&quot; is another story, which is Javascript way, where basic JS<br/>&gt; engine V8 is single-threaded.<br/>&gt; &gt;<br/>&gt; &gt;<br/>&gt; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259757.html Fri, 09 Apr 2021 05:53:59 +0000 Re: on changing perl's behavior by B. Estrade <br/><br/>On 4/8/21 9:23 PM, Ricardo Signes wrote:<br/>&gt; On Thu, Apr 8, 2021, at 5:18 PM, Todd Rinaldo wrote:<br/>&gt;&gt;&gt; Outside of that, when a huge win can be demonstrated, stuff should be <br/>&gt;&gt;&gt; removed, but then i&#39;d prefer it be done by way of deprecating that <br/>&gt;&gt;&gt; specific dialect.<br/>&gt;&gt;<br/>&gt;&gt; I would argue (though it&#39;s hard to search for &quot;format&quot; in the issues <br/>&gt;&gt; list) that being able to close 50+ cases would be nice if we could <br/>&gt;&gt; just say: &quot;Formats are removed. this issue is now irrelevant.&quot;<br/>&gt; <br/>&gt; I think that&#39;s true, strictly speaking, but:&nbsp; of the people who use <br/>&gt; formats, how many would be impacted, and how, if we removed formats? <br/>&gt; Well, 100% of them would be impacted, and the impact would be &quot;I had to <br/>&gt; rewrite some code&quot; which (given how formats work) would probably be kind <br/>&gt; of a pain in the butt.&nbsp; Sometimes a big one, sometimes pretty tiny.<br/>&gt; <br/>&gt; On the other hand, the benefit of closing tickets that we were ignoring <br/>&gt; /anyway/&nbsp;is pretty darn low.<br/><br/>Might you have a sampling of such tickets? Please don&#39;t read into the <br/>request, I am more curious than anything.<br/><br/>Thank you,<br/>Brett<br/><br/>&gt; <br/>&gt; Christian&#39;s #2, changing defaults when they confound users, should be <br/>&gt; weighed against users confounded.&nbsp; I think we&#39;d find that in general, <br/>&gt; new users are not reaching for formats.&nbsp; If users say &quot;I&#39;m using <br/>&gt; formats, and this part was confusing,&quot; and we say, &quot;okay, we have ripped <br/>&gt; out formats,&quot; I don&#39;t think anybody&#39;s going to thank us for that.<br/>&gt; <br/>&gt; -- <br/>&gt; rjbs<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259756.html Fri, 09 Apr 2021 04:51:34 +0000 by Yuki Kimoto B. Estrade <br/> <br/>I don&#39;t yet understand what you want. <br/> <br/>If you want to call OpenMP easily, I&#39;m also trying in my SPVM module. <br/> <br/>https://github.com/yuki-kimoto/SPVM/tree/master/examples/native/openmp <br/> <br/>Perl already has Inline::C/XS/FFIs modules. SPVM is another way to bind C <br/>libraries. <br/> <br/>More example <br/> <br/>-cuda <br/>-Eigen <br/>-GSL <br/>-OpenCV <br/>-zlib <br/> <br/>https://github.com/yuki-kimoto/SPVM/tree/master/examples/native <br/> <br/>2021&aring;&sup1;&acute;4&aelig;&#156;&#136;9&aelig;&#151;&yen;(&eacute;&#135;&#145;) 0:05 B. Estrade &lt;brett@cpanel.net&gt;: <br/> <br/>&gt; Thank you, appreciate the reply. To avoid collision with the other <br/>&gt; thread, I update the subject. <br/>&gt; <br/>&gt; So I suppose this cuts to the heart of the matter. It&#39;s fair, I believe, <br/>&gt; that &quot;top level &#39;threading&#39;&quot; is not something that can be reasonable <br/>&gt; supported in the perl runtime (and to be fair, other scripting languages <br/>&gt; also struggle greatly with this). <br/>&gt; <br/>&gt; The question, then goes to: how do we facilitate access to the native <br/>&gt; platform&#39;s SMP? Perhaps the answer is, as always, &quot;it depends.&quot; <br/>&gt; <br/>&gt; I will continue to pound my head on this, something will shake loose. In <br/>&gt; the meantime, as proof that I am vested in seeing some interesting <br/>&gt; options shake loose, I have offered a module on CPAN called <br/>&gt; OpenMP::Environment. <br/>&gt; <br/>&gt; It only provides programmatic manipulation of the environmental <br/>&gt; variables that OpenMP programs care about; but it is a necessary step <br/>&gt; for me to investigate and gain some intuition about what is possible and <br/>&gt; what looks &quot;right&quot;. <br/>&gt; <br/>&gt; Currently I am thinking a SIMD (single instruction, multiple data) <br/>&gt; approach is the most accessible. This doesn&#39;t really get at what is <br/>&gt; ideal (in my mind), but at least provides a path forward by creating <br/>&gt; threaded libraries made available via Inline::C/XS/FFIs - and even <br/>&gt; leveraging these via a tie interface. And if the direction of providing <br/>&gt; SIMD &quot;data types&quot; is truly the best direction, PDL seems like a really <br/>&gt; good target for that. <br/>&gt; <br/>&gt; Thanks for all the feedback, will monitor the list/thread. I do ask that <br/>&gt; we keep the whole idea of threading &quot;where and when feasible&quot; (even in <br/>&gt; language design considerations) is extremely important to Perl&#39;s long <br/>&gt; term viability and as a driver of important capabilities. The idea of <br/>&gt; using Perl to efficiently max out a large SMP machine for useful work is <br/>&gt; very exciting to me, and I think I am not the only one. <br/>&gt; <br/>&gt; Cheers, <br/>&gt; Brett <br/>&gt; <br/>&gt; <br/>&gt; On 4/8/21 3:42 AM, Konovalov, Vadim wrote: <br/>&gt; &gt;&gt; Nicholas Clark &lt;nick@ccl4.org&gt; wrote: <br/>&gt; &gt;&gt;&gt; On Wed, Apr 07, 2021 at 10:49:05AM -0500, B. Estrade wrote: <br/>&gt; &gt;&gt;&gt; <br/>&gt; &gt;&gt;&gt;&gt; Here&#39;s some food for thought. When was was the last time anyone had a <br/>&gt; &gt;&gt;&gt;&gt; serious discussion of introducing smp thread safety into the <br/>&gt; language? Or <br/>&gt; &gt;&gt;&gt;&gt; easy access to atomics? These are, IMO, 2 very important and serious <br/>&gt; things <br/>&gt; &gt;&gt;&gt; <br/>&gt; &gt;&gt;&gt; Retrofitting proper multicore concurrency to perl would imply that it&#39;s <br/>&gt; &gt;&gt;&gt; possible at all. <br/>&gt; &gt;&gt;&gt; <br/>&gt; &gt;&gt;&gt; None of the comparable C-based dynamic languages have done it (eg <br/>&gt; Python, <br/>&gt; &gt;&gt;&gt; Ruby) <br/>&gt; &gt; <br/>&gt; &gt; Both Python and Ruby are not a good place to learn on how <br/>&gt; multiprocessing happens. <br/>&gt; &gt; There is much better place to learn from - Julia. <br/>&gt; &gt; <br/>&gt; &gt; Julia made interesting approach: syntax highly inspired by Python, but <br/>&gt; correctly <br/>&gt; &gt; deals with multithreading. In a sense - this is much developed Python <br/>&gt; with all missing <br/>&gt; &gt; features added into completely different language. <br/>&gt; &gt; <br/>&gt; &gt; Very interesting approach, and I suppose this is about what perl <br/>&gt; community intended <br/>&gt; &gt; to implement when perl6 discussion have begun in 2000. <br/>&gt; &gt; <br/>&gt; &gt; <br/>&gt; &gt; <br/>&gt; &gt;&gt;&gt; Ruby&#39;s new experimental new threading is an actor model (I believe) <br/>&gt; CPython <br/>&gt; &gt;&gt;&gt; is dogged by the GIL (all the threads you like, but if you&#39;re CPU <br/>&gt; bound then <br/>&gt; &gt;&gt;&gt; you&#39;re making one core very toasty) The seem to be thinking about going <br/>&gt; &gt;&gt;&gt; multicore by doing something like ithreads (using pickle to pass data <br/>&gt; &gt;&gt;&gt; structures between MULITPLICITY-like interpreters) but that&#39;s likely <br/>&gt; going <br/>&gt; &gt;&gt;&gt; to be as good as ithreads. <br/>&gt; &gt; <br/>&gt; &gt; It appears that reference counting + threading results in considerable <br/>&gt; slow down <br/>&gt; &gt; and the solution to the problem is good GC. <br/>&gt; &gt; This was &quot;proved&quot; by GILectomy project, see any google video on this or <br/>&gt; this <br/>&gt; &gt; nice summary https://news.ycombinator.com/item?id=11842779 <br/>&gt; &gt; <br/>&gt; &gt; Perl history on threading (PERL5005THREADS and then ITHREADS where 1st <br/>&gt; was <br/>&gt; &gt; deprecated and removed while 2nd was recently deprecated) gives me think <br/>&gt; &gt; that no real multithreading/multicoring is actually possible on language <br/>&gt; level. <br/>&gt; &gt; Developing into that direction now is just wasting of time. <br/>&gt; &gt; <br/>&gt; &gt; &quot;async&quot; is another story, which is Javascript way, where basic JS engine <br/>&gt; V8 is single-threaded. <br/>&gt; &gt; <br/>&gt; &gt; <br/>&gt; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259755.html Fri, 09 Apr 2021 04:51:08 +0000 Re: on changing perl's behavior by Ricardo Signes On Thu, Apr 8, 2021, at 5:18 PM, Todd Rinaldo wrote:<br/>&gt;&gt; Outside of that, when a huge win can be demonstrated, stuff should be removed, but then i&#39;d prefer it be done by way of deprecating that specific dialect.<br/>&gt; <br/>&gt; I would argue (though it&#39;s hard to search for &quot;format&quot; in the issues list) that being able to close 50+ cases would be nice if we could just say: &quot;Formats are removed. this issue is now irrelevant.&quot; <br/><br/>I think that&#39;s true, strictly speaking, but: of the people who use formats, how many would be impacted, and how, if we removed formats? Well, 100% of them would be impacted, and the impact would be &quot;I had to rewrite some code&quot; which (given how formats work) would probably be kind of a pain in the butt. Sometimes a big one, sometimes pretty tiny.<br/><br/>On the other hand, the benefit of closing tickets that we were ignoring *anyway* is pretty darn low.<br/><br/>Christian&#39;s #2, changing defaults when they confound users, should be weighed against users confounded. I think we&#39;d find that in general, new users are not reaching for formats. If users say &quot;I&#39;m using formats, and this part was confusing,&quot; and we say, &quot;okay, we have ripped out formats,&quot; I don&#39;t think anybody&#39;s going to thank us for that.<br/><br/>-- <br/>rjbs https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259754.html Fri, 09 Apr 2021 02:24:23 +0000 Re: CPAN release of ExtUtils-ParseXS by Ben Bullock On Thu, 8 Apr 2021 at 22:47, James E Keenan &lt;jkeenan@pobox.com&gt; wrote:<br/><br/>&gt; Ben, I&#39;m concerned that in your tarball you are not completely capturing<br/>&gt; the state of ExtUtils-ParseXS as it currently appears in blead. As a<br/>&gt; consequence, if you were to release what&#39;s in your tarball to CPAN, what<br/>&gt; is stated to be version 3.43 on CPAN would be subtly different from what<br/>&gt; will presumably be version 3.43 in dist/ExtUtils-ParseXS when we release<br/>&gt; perl-5.34.0 next month.<br/><br/>I personally am not currently due to release anything to CPAN, I&#39;m<br/>just doing the work on preparing the files for release. The current<br/>job is to review the changes and check the files are all OK.<br/><br/>&gt; Now, if (a) I download and unpack your tarball, then (b) do a &quot;git<br/>&gt; checkout 99155265&quot;, and then (c) diff blead against your tarball, I come<br/>&gt; up with the diff attached (eupp.99155265b6.vs.proposed.diff). Much of<br/>&gt; the diff is housekeeping, but I&#39;m concerned that Ed J&#39;s changes don&#39;t<br/>&gt; make the diff. Also missing are changes to<br/>&gt; dist/ExtUtils-ParseXS/t/XSTest.xs and dist/ExtUtils-ParseXS/t/XSUsage.xs<br/>&gt; that were committed in Nov 2017 in commit a8c15670317. The most<br/>&gt; relevant differences I am attaching as &quot;relevant.diff&quot;.<br/><br/>We lost some changes because I didn&#39;t copy /t/ properly. Originally I<br/>copied all the files under dist/ExtUtils-ParseXS, then found that the<br/>perldoc files in lib weren&#39;t part of the dual-life distribution by<br/>Stefan Mueller on CPAN, so I just copied lib, to omit the perldoc<br/>files, and forgot to copy /t/. I&#39;ve now copied this and made a new tag<br/>release here:<br/><br/>https://github.com/benkasminbullock/extutils-parsexs/releases/tag/3.43_02<br/><br/>Could you check it again?<br/><br/>&gt; I want to further acknowledge that dual-life-ing of ExtUtils-ParseXS is<br/>&gt; particularly challenging, as its Makefile in core is automatically<br/>&gt; generated while its Makefile.PL on CPAN is rather complicated.<br/><br/>The Makefile.PL in the above is copied from the CPAN one, not from the<br/>distro files.<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259753.html Thu, 08 Apr 2021 21:22:49 +0000 Re: on changing perl's behavior by Todd Rinaldo <br/> <br/>&gt; On Apr 7, 2021, at 10:31 AM, Christian Walde &lt;walde.christian@gmail.com&gt; wrote: <br/>&gt; <br/>&gt; On Wed, 07 Apr 2021 15:26:55 +0200, Nicholas Clark &lt;nick@ccl4.org&gt; wrote: <br/>&gt; <br/>&gt;&gt; So the point that I&#39;d like to make is that there are *some* things that <br/>&gt;&gt; might be removed to simplify the internals and reduce the support burden, <br/>&gt;&gt; but *most* existing things don&#39;t get in the way, at least at runtime. <br/>&gt; <br/>&gt; Thanks for adding more detail. I really appreciate that effort to provide tangible evidence for this. :) <br/>&gt; <br/>&gt; A small addendum: <br/>&gt; <br/>&gt; I think it&#39;s fine to change the defaults in these cases: <br/>&gt; <br/>&gt; 1. when the behavior is a security risk <br/>&gt; 2. when the behavior is outright broken and subverts expectations and optimally also documentation <br/>&gt; 3. when actually finding examples of anybody using the behavior is nearly impossible <br/>&gt; <br/>&gt; I think your examples all fall under 3.? <br/>&gt; <br/>&gt; Outside of that, when a huge win can be demonstrated, stuff should be removed, but then i&#39;d prefer it be done by way of deprecating that specific dialect. <br/> <br/> <br/>I would argue (though it&#39;s hard to search for &quot;format&quot; in the issues list) that being able to close 50+ cases would be nice if we could just say: &quot;Formats are removed. this issue is now irrelevant.&quot; <br/> <br/>For me all of that would fall under #2. <br/> <br/>Todd https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259752.html Thu, 08 Apr 2021 21:18:56 +0000 Re: On the Decline of Perl [internal factors] by Todd Rinaldo <br/> <br/>&gt; On Mar 27, 2021, at 7:00 PM, Paul LeoNerd Evans &lt;leonerd@leonerd.org.uk&gt; wrote: <br/>&gt; <br/>&gt; Last year there was a push to bring the core perl files a bit more up <br/>&gt; to date, at least to ensure that all the core unit tests are <br/>&gt; strict/warnings safe. Even right now I notice several that are not. Why <br/>&gt; have we not kept our own house in order, even to the point of <br/>&gt; `use strict + use warnings` in every file? Again, lack of people/time <br/>&gt; to do it. <br/>&gt; <br/> <br/>Paul, <br/> <br/>I&#39;m late replying but some of this work was me. I wanted to explain why I disengaged from the process. <br/> <br/>While much of the code review on these merges were very helpful, some of it was very wearing. In some cases I didn&#39;t agree with the code review but our workflow on what to do when there&#39;s disagreement is non-existant. This is on hold primarily because I was waiting on some direction from the PSC before I re-engage. <br/> <br/>I would love for us to have some coding standards. <br/>I woulld love for us to have policies on what should and shouldn&#39;t block a pull request merge. <br/>I would LOVE for us to have perltidy standards for merge. I&#39;d even vote for making it dual life. <br/> <br/>The PSC is aware of my desires but there are other priorities they (IMO) should sort first. <br/> <br/>Todd <br/> <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259751.html Thu, 08 Apr 2021 19:37:47 +0000 Re: Pluggable infix operators by Paul "LeoNerd" Evans On Thu, 8 Apr 2021 18:09:12 +0200<br/>Leon Timmermans &lt;fawaka@gmail.com&gt; wrote:<br/><br/>&gt; Why is an XS module necessary? Why can&#39;t that functionality be part of<br/>&gt; core itself? That doesn&#39;t seem to be explained here.<br/><br/>Perhaps it could eventually once it becomes stable.<br/><br/>Right now I find it gives me a much faster iteration speed putting it<br/>in an XS module. Currently in terms of rebuild times, and if this<br/>becomes a core feature, in terms of CPAN module release times.<br/><br/>-- <br/>Paul &quot;LeoNerd&quot; Evans<br/><br/>leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS<br/>http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259750.html Thu, 08 Apr 2021 16:17:16 +0000 Re: Pluggable infix operators by Leon Timmermans On Sat, Apr 3, 2021 at 12:38 AM Paul &quot;LeoNerd&quot; Evans<br/>&lt;leonerd@leonerd.org.uk&gt; wrote:<br/>&gt; I will expand more on that topic in a later email, but briefly here the<br/>&gt; module is built on top of the underlying hook mechanism which needs<br/>&gt; adding to core perl. My intention would be that the base level hook<br/>&gt; mechanism isn&#39;t really documented very much, and discouraged from<br/>&gt; direct use - instead this module would be the preferred way for XS<br/>&gt; authors to interact with it.<br/><br/>Why is an XS module necessary? Why can&#39;t that functionality be part of<br/>core itself? That doesn&#39;t seem to be explained here.<br/><br/>Leon<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259749.html Thu, 08 Apr 2021 16:09:38 +0000 =?UTF-8?Q?Re=3A_Perl=E2=80=99s_leaky_bucket?= by Leon Timmermans On Wed, Apr 7, 2021 at 9:41 PM Nicholas Clark &lt;nick@ccl4.org&gt; wrote:<br/>&gt; Ruby&#39;s new experimental new threading is an actor model (I believe)<br/><br/>I do have a project doing actor model (much like erlang) on top of<br/>ithreads (but not threads.pm); and I was planning to look into CSP<br/>(much like go&#39;s channels) as well. I do also think this is useful, but<br/>it&#39;s not necessary what people are looking for when they say<br/>multi-threading.<br/><br/>Leon<br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259748.html Thu, 08 Apr 2021 16:09:05 +0000 by B. Estrade Thank you, appreciate the reply. To avoid collision with the other <br/>thread, I update the subject.<br/><br/>So I suppose this cuts to the heart of the matter. It&#39;s fair, I believe, <br/>that &quot;top level &#39;threading&#39;&quot; is not something that can be reasonable <br/>supported in the perl runtime (and to be fair, other scripting languages <br/>also struggle greatly with this).<br/><br/>The question, then goes to: how do we facilitate access to the native <br/>platform&#39;s SMP? Perhaps the answer is, as always, &quot;it depends.&quot;<br/><br/>I will continue to pound my head on this, something will shake loose. In <br/>the meantime, as proof that I am vested in seeing some interesting <br/>options shake loose, I have offered a module on CPAN called <br/>OpenMP::Environment.<br/><br/>It only provides programmatic manipulation of the environmental <br/>variables that OpenMP programs care about; but it is a necessary step <br/>for me to investigate and gain some intuition about what is possible and <br/>what looks &quot;right&quot;.<br/><br/>Currently I am thinking a SIMD (single instruction, multiple data) <br/>approach is the most accessible. This doesn&#39;t really get at what is <br/>ideal (in my mind), but at least provides a path forward by creating <br/>threaded libraries made available via Inline::C/XS/FFIs - and even <br/>leveraging these via a tie interface. And if the direction of providing <br/>SIMD &quot;data types&quot; is truly the best direction, PDL seems like a really <br/>good target for that.<br/><br/>Thanks for all the feedback, will monitor the list/thread. I do ask that <br/>we keep the whole idea of threading &quot;where and when feasible&quot; (even in <br/>language design considerations) is extremely important to Perl&#39;s long <br/>term viability and as a driver of important capabilities. The idea of <br/>using Perl to efficiently max out a large SMP machine for useful work is <br/>very exciting to me, and I think I am not the only one.<br/><br/>Cheers,<br/>Brett<br/><br/><br/>On 4/8/21 3:42 AM, Konovalov, Vadim wrote:<br/>&gt;&gt; Nicholas Clark &lt;nick@ccl4.org&gt; wrote:<br/>&gt;&gt;&gt; On Wed, Apr 07, 2021 at 10:49:05AM -0500, B. Estrade wrote:<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt;&gt; Here&#39;s some food for thought. When was was the last time anyone had a<br/>&gt;&gt;&gt;&gt; serious discussion of introducing smp thread safety into the language? Or<br/>&gt;&gt;&gt;&gt; easy access to atomics? These are, IMO, 2 very important and serious things<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; Retrofitting proper multicore concurrency to perl would imply that it&#39;s<br/>&gt;&gt;&gt; possible at all.<br/>&gt;&gt;&gt;<br/>&gt;&gt;&gt; None of the comparable C-based dynamic languages have done it (eg Python,<br/>&gt;&gt;&gt; Ruby)<br/>&gt; <br/>&gt; Both Python and Ruby are not a good place to learn on how multiprocessing happens.<br/>&gt; There is much better place to learn from - Julia.<br/>&gt; <br/>&gt; Julia made interesting approach: syntax highly inspired by Python, but correctly<br/>&gt; deals with multithreading. In a sense - this is much developed Python with all missing<br/>&gt; features added into completely different language.<br/>&gt; <br/>&gt; Very interesting approach, and I suppose this is about what perl community intended<br/>&gt; to implement when perl6 discussion have begun in 2000.<br/>&gt; <br/>&gt; <br/>&gt; <br/>&gt;&gt;&gt; Ruby&#39;s new experimental new threading is an actor model (I believe) CPython<br/>&gt;&gt;&gt; is dogged by the GIL (all the threads you like, but if you&#39;re CPU bound then<br/>&gt;&gt;&gt; you&#39;re making one core very toasty) The seem to be thinking about going<br/>&gt;&gt;&gt; multicore by doing something like ithreads (using pickle to pass data<br/>&gt;&gt;&gt; structures between MULITPLICITY-like interpreters) but that&#39;s likely going<br/>&gt;&gt;&gt; to be as good as ithreads.<br/>&gt; <br/>&gt; It appears that reference counting + threading results in considerable slow down<br/>&gt; and the solution to the problem is good GC.<br/>&gt; This was &quot;proved&quot; by GILectomy project, see any google video on this or this<br/>&gt; nice summary https://news.ycombinator.com/item?id=11842779<br/>&gt; <br/>&gt; Perl history on threading (PERL5005THREADS and then ITHREADS where 1st was<br/>&gt; deprecated and removed while 2nd was recently deprecated) gives me think<br/>&gt; that no real multithreading/multicoring is actually possible on language level.<br/>&gt; Developing into that direction now is just wasting of time.<br/>&gt; <br/>&gt; &quot;async&quot; is another story, which is Javascript way, where basic JS engine V8 is single-threaded.<br/>&gt; <br/>&gt; <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259747.html Thu, 08 Apr 2021 15:05:17 +0000 Re: CPAN release of ExtUtils-ParseXS by James E Keenan On 4/7/21 10:10 PM, James E Keenan wrote:<br/>&gt; Ben Bullock wrote:<br/>&gt; <br/>&gt; #####<br/>&gt; I&#39;ve assembled a pre-release here:<br/>&gt; <br/>&gt; https://github.com/benkasminbullock/extutils-parsexs/releases/tag/3.43_01<br/>&gt; #####<br/>&gt; <br/>&gt; What is the point (commit) in Perl 5 blead to which we should be <br/>&gt; comparing the code in the tarball at the above URL?<br/>&gt; <br/>&gt; (It appears to be later than perl-5.32.1 but earlier than HEAD.)<br/>&gt; <br/><br/>Ben, I&#39;m concerned that in your tarball you are not completely capturing <br/>the state of ExtUtils-ParseXS as it currently appears in blead. As a <br/>consequence, if you were to release what&#39;s in your tarball to CPAN, what <br/>is stated to be version 3.43 on CPAN would be subtly different from what <br/>will presumably be version 3.43 in dist/ExtUtils-ParseXS when we release <br/>perl-5.34.0 next month.<br/><br/>If we look at Perl 5 blead we see that the last changes to <br/>dist/ExtUtils-ParseXS were a series of 4 commits on March 24 of this <br/>year, 2 of which were substantive fixes submitted by Ed J and 2 of which <br/>were p5p housekeeping by me:<br/><br/>#####<br/>$ git log --format=fuller --reverse <br/>7365f8f7fa7940e5e4422c10fc07c18aa0447ee3..HEAD -- dist/ExtUtils-ParseXS/ <br/>|cat<br/>commit e3a57d70d0b8c89c2c37833064dd4e2ecc302b58<br/>Author: Ed J &lt;mohawk2@users.noreply.github.com&gt;<br/>AuthorDate: Sat Mar 20 16:35:25 2021 +0000<br/>Commit: James E Keenan &lt;jkeenan@cpan.org&gt;<br/>CommitDate: Wed Mar 24 08:41:56 2021 -0400<br/><br/> use PERL_VERSION_LE not 5.33+ PERL_VERSION_LT<br/><br/> As ExtUtils::ParseXS is dual-life it needs to use stable Perl macros.<br/><br/>commit f1f3e1235de245a2fc5947224992ed28b9e75f99<br/>Author: Ed J &lt;mohawk2@users.noreply.github.com&gt;<br/>AuthorDate: Sun Apr 21 22:18:13 2019 +0100<br/>Commit: James E Keenan &lt;jkeenan@cpan.org&gt;<br/>CommitDate: Wed Mar 24 08:41:56 2021 -0400<br/><br/> ExtUtils::ParseXS fix error-message bug<br/><br/>commit 7ed63354fd06d48bccb0abf1278e6333edf41536<br/>Author: James E Keenan &lt;jkeenan@cpan.org&gt;<br/>AuthorDate: Wed Mar 24 14:20:46 2021 +0000<br/>Commit: James E Keenan &lt;jkeenan@cpan.org&gt;<br/>CommitDate: Wed Mar 24 14:20:46 2021 +0000<br/><br/> Bump $VERSION to keep porting tests happy<br/><br/>commit 99155265b6644bc3178a61cd413e989b2ecf90d9<br/>Author: James E Keenan &lt;jkeenan@cpan.org&gt;<br/>AuthorDate: Wed Mar 24 10:44:08 2021 -0400<br/>Commit: James E Keenan &lt;jkeenan@cpan.org&gt;<br/>CommitDate: Wed Mar 24 10:44:08 2021 -0400<br/><br/> Bump $VERSION throughout dist/ExtUtils-ParseXS/lib<br/><br/> Build was gagging after mktables.lst.<br/>#####<br/><br/>So, if I had been asked to prepare a CPAN release of ExtUtils-ParseXS, <br/>commit 99155265 would have been my starting point.<br/><br/>Now, if (a) I download and unpack your tarball, then (b) do a &quot;git <br/>checkout 99155265&quot;, and then (c) diff blead against your tarball, I come <br/>up with the diff attached (eupp.99155265b6.vs.proposed.diff). Much of <br/>the diff is housekeeping, but I&#39;m concerned that Ed J&#39;s changes don&#39;t <br/>make the diff. Also missing are changes to <br/>dist/ExtUtils-ParseXS/t/XSTest.xs and dist/ExtUtils-ParseXS/t/XSUsage.xs <br/>that were committed in Nov 2017 in commit a8c15670317. The most <br/>relevant differences I am attaching as &quot;relevant.diff&quot;.<br/><br/>Up until now most CPAN releases of blead-upstream, dual-life modules <br/>(i.e., those under dist/) have been performed by whoever was the current <br/>pumpking. It has not been a widely distributed task and, perhaps as a <br/>consequence, we lack (to the best of my knowledge) specific instructions <br/>for doing such releases. So it&#39;s not surprising that there may be <br/>confusion or differences of opinion as to &quot;where do we start from.&quot;<br/><br/>I want to further acknowledge that dual-life-ing of ExtUtils-ParseXS is <br/>particularly challenging, as its Makefile in core is automatically <br/>generated while its Makefile.PL on CPAN is rather complicated.<br/><br/>Sawyer, Rik, can we get clarification on this?<br/><br/>Thank you very much.<br/>Jim Keenan<br/><br/><br/><br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259746.html Thu, 08 Apr 2021 13:47:39 +0000 =?utf-8?B?UkU6IFBlcmzigJlzIGxlYWt5IGJ1Y2tldA==?= by Konovalov, Vadim &gt; Nicholas Clark &lt;nick@ccl4.org&gt; wrote: <br/>&gt; &gt; On Wed, Apr 07, 2021 at 10:49:05AM -0500, B. Estrade wrote: <br/>&gt; &gt; <br/>&gt; &gt; &gt; Here&#39;s some food for thought. When was was the last time anyone had a <br/>&gt; &gt; &gt; serious discussion of introducing smp thread safety into the language? Or <br/>&gt; &gt; &gt; easy access to atomics? These are, IMO, 2 very important and serious things <br/>&gt; &gt; <br/>&gt; &gt; Retrofitting proper multicore concurrency to perl would imply that it&#39;s <br/>&gt; &gt; possible at all. <br/>&gt; &gt; <br/>&gt; &gt; None of the comparable C-based dynamic languages have done it (eg Python, <br/>&gt; &gt; Ruby) <br/> <br/>Both Python and Ruby are not a good place to learn on how multiprocessing happens. <br/>There is much better place to learn from - Julia. <br/> <br/>Julia made interesting approach: syntax highly inspired by Python, but correctly <br/>deals with multithreading. In a sense - this is much developed Python with all missing <br/>features added into completely different language. <br/> <br/>Very interesting approach, and I suppose this is about what perl community intended <br/>to implement when perl6 discussion have begun in 2000. <br/> <br/> <br/> <br/>&gt; &gt; Ruby&#39;s new experimental new threading is an actor model (I believe) CPython <br/>&gt; &gt; is dogged by the GIL (all the threads you like, but if you&#39;re CPU bound then <br/>&gt; &gt; you&#39;re making one core very toasty) The seem to be thinking about going <br/>&gt; &gt; multicore by doing something like ithreads (using pickle to pass data <br/>&gt; &gt; structures between MULITPLICITY-like interpreters) but that&#39;s likely going <br/>&gt; &gt; to be as good as ithreads. <br/> <br/>It appears that reference counting + threading results in considerable slow down <br/>and the solution to the problem is good GC. <br/>This was &quot;proved&quot; by GILectomy project, see any google video on this or this <br/>nice summary https://news.ycombinator.com/item?id=11842779 <br/> <br/>Perl history on threading (PERL5005THREADS and then ITHREADS where 1st was <br/>deprecated and removed while 2nd was recently deprecated) gives me think <br/>that no real multithreading/multicoring is actually possible on language level. <br/>Developing into that direction now is just wasting of time. <br/> <br/>&quot;async&quot; is another story, which is Javascript way, where basic JS engine V8 is single-threaded. <br/> <br/> <br/> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259745.html Thu, 08 Apr 2021 08:42:26 +0000