Re: HTTP and MPM support
We also use threads without any problem in production. Main use is sharing caches so that multiple mod_perl interpreters don'teach store the same cached information. Following a few simple and documented rules, we've had no issues with using threads. On Mon, Jan 28, 2019 at 6:18 PM Mark Blackman wrote: > > > > On 28 Jan 2019, at 23:00, Paul B. Henson wrote: > > > > On 1/28/2019 1:53 PM, Mark Blackman wrote: > >> https://perldoc.perl.org/threads.html#WARNING Threads are discouraged > in Perl these days > > > > Yes, that is indeed what the documentation says; however, there is a far > cry between "Perl is single-threaded by design and history and has no > reliable support for threading" and "use of threads is discouraged in perl". > > > > Looking back to the original discussion that led to that caveat > https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html > a good summary of why it is there is: > > > > "The patch came about because unmanaged expectations of support are > causing social problems" > > > > And further discussion about it > https://www.perlmonks.org/?node_id=1107534 has a similar insight: > > > > "that this particular formulation is just smoke and mirrors to repel > 'annoying newbies" > > > > Then in this bug discussing the verbiage > https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer > comments: > > > > "The fact is that threads work, they are maintained, and they currently > do not have any bugs preventing their use." > > > > Basically, perl threads are heavyweight, not lightweight, and use of > non-thread safe Perl code whether your own or in third-party modules will > cause potentially nondeterministic problems. The warning is basically there > to scare away people who don't have sufficient expertise to make it work > and will likely come complain and ask for help with something the > developers don't want to have to explain over and over again. > > > > Back when I was running DCE/DFS and maintaining the perl modules on top > of that, I used threaded perl heavily with no issues. As long as the > mechanism of and caveats regarding Perl threads are understood, and there > is a justifiable reason to be using them rather than some other construct, > discouraged is not deprecated nor unavailable/unreliable. > > "Threads are implemented in a way that make them easy to misuse." == > "single threaded by design” in my book, but your mileage may vary. I > believe threads were retrofitted to Perl and I see very little use of > threads in the wild myself. Relying on threads in Perl with real-world > third-party XS modules that aren’t thread-safe is equivalent to unreliable. > Base Perl might be safe enough, but nobody runs real-world apps with pure > Perl alone IME. > > I am glad you made threads work well in production, but I suspect you’re > in a minority. > > - Mark > > > >
Re: HTTP and MPM support
We've used Cache::FastMmap at my work to share data between mod_perl processes. We did not consider using threads because they're not lightweight. What the rules you guys are following when it comes to using threads? On Tue, Jan 29, 2019 at 9:48 AM John Deighan wrote: > We also use threads without any problem in production. Main use is sharing > caches so that multiple mod_perl interpreters don'teach store the same > cached information. Following a few simple and documented rules, we've had > no issues with using threads. > > On Mon, Jan 28, 2019 at 6:18 PM Mark Blackman wrote: > >> >> >> > On 28 Jan 2019, at 23:00, Paul B. Henson wrote: >> > >> > On 1/28/2019 1:53 PM, Mark Blackman wrote: >> >> https://perldoc.perl.org/threads.html#WARNING Threads are >> discouraged in Perl these days >> > >> > Yes, that is indeed what the documentation says; however, there is a >> far cry between "Perl is single-threaded by design and history and has no >> reliable support for threading" and "use of threads is discouraged in perl". >> > >> > Looking back to the original discussion that led to that caveat >> https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html >> a good summary of why it is there is: >> > >> > "The patch came about because unmanaged expectations of support are >> causing social problems" >> > >> > And further discussion about it >> https://www.perlmonks.org/?node_id=1107534 has a similar insight: >> > >> > "that this particular formulation is just smoke and mirrors to repel >> 'annoying newbies" >> > >> > Then in this bug discussing the verbiage >> https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer >> comments: >> > >> > "The fact is that threads work, they are maintained, and they currently >> do not have any bugs preventing their use." >> > >> > Basically, perl threads are heavyweight, not lightweight, and use of >> non-thread safe Perl code whether your own or in third-party modules will >> cause potentially nondeterministic problems. The warning is basically there >> to scare away people who don't have sufficient expertise to make it work >> and will likely come complain and ask for help with something the >> developers don't want to have to explain over and over again. >> > >> > Back when I was running DCE/DFS and maintaining the perl modules on top >> of that, I used threaded perl heavily with no issues. As long as the >> mechanism of and caveats regarding Perl threads are understood, and there >> is a justifiable reason to be using them rather than some other construct, >> discouraged is not deprecated nor unavailable/unreliable. >> >> "Threads are implemented in a way that make them easy to misuse." == >> "single threaded by design” in my book, but your mileage may vary. I >> believe threads were retrofitted to Perl and I see very little use of >> threads in the wild myself. Relying on threads in Perl with real-world >> third-party XS modules that aren’t thread-safe is equivalent to unreliable. >> Base Perl might be safe enough, but nobody runs real-world apps with pure >> Perl alone IME. >> >> I am glad you made threads work well in production, but I suspect you’re >> in a minority. >> >> - Mark >> >> >> >>
Re: HTTP and MPM support
We use Redis to share information between mod_perl processes(including our HTTP sessions). This has the added advantage of allowing all servers in a cluster to share the same session/cache. On Tue, Jan 29, 2019 at 7:38 PM Narbey Derbekyan wrote: > We've used Cache::FastMmap at my work to share data between mod_perl > processes. We did not consider using threads because they're not > lightweight. > What the rules you guys are following when it comes to using threads? > > On Tue, Jan 29, 2019 at 9:48 AM John Deighan > wrote: > >> We also use threads without any problem in production. Main use is >> sharing caches so that multiple mod_perl interpreters don'teach store the >> same cached information. Following a few simple and documented rules, we've >> had no issues with using threads. >> >> On Mon, Jan 28, 2019 at 6:18 PM Mark Blackman wrote: >> >>> >>> >>> > On 28 Jan 2019, at 23:00, Paul B. Henson wrote: >>> > >>> > On 1/28/2019 1:53 PM, Mark Blackman wrote: >>> >> https://perldoc.perl.org/threads.html#WARNING Threads are >>> discouraged in Perl these days >>> > >>> > Yes, that is indeed what the documentation says; however, there is a >>> far cry between "Perl is single-threaded by design and history and has no >>> reliable support for threading" and "use of threads is discouraged in perl". >>> > >>> > Looking back to the original discussion that led to that caveat >>> https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html >>> a good summary of why it is there is: >>> > >>> > "The patch came about because unmanaged expectations of support are >>> causing social problems" >>> > >>> > And further discussion about it >>> https://www.perlmonks.org/?node_id=1107534 has a similar insight: >>> > >>> > "that this particular formulation is just smoke and mirrors to repel >>> 'annoying newbies" >>> > >>> > Then in this bug discussing the verbiage >>> https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer >>> comments: >>> > >>> > "The fact is that threads work, they are maintained, and they >>> currently do not have any bugs preventing their use." >>> > >>> > Basically, perl threads are heavyweight, not lightweight, and use of >>> non-thread safe Perl code whether your own or in third-party modules will >>> cause potentially nondeterministic problems. The warning is basically there >>> to scare away people who don't have sufficient expertise to make it work >>> and will likely come complain and ask for help with something the >>> developers don't want to have to explain over and over again. >>> > >>> > Back when I was running DCE/DFS and maintaining the perl modules on >>> top of that, I used threaded perl heavily with no issues. As long as the >>> mechanism of and caveats regarding Perl threads are understood, and there >>> is a justifiable reason to be using them rather than some other construct, >>> discouraged is not deprecated nor unavailable/unreliable. >>> >>> "Threads are implemented in a way that make them easy to misuse." == >>> "single threaded by design” in my book, but your mileage may vary. I >>> believe threads were retrofitted to Perl and I see very little use of >>> threads in the wild myself. Relying on threads in Perl with real-world >>> third-party XS modules that aren’t thread-safe is equivalent to unreliable. >>> Base Perl might be safe enough, but nobody runs real-world apps with pure >>> Perl alone IME. >>> >>> I am glad you made threads work well in production, but I suspect you’re >>> in a minority. >>> >>> - Mark >>> >>> >>> >>> -- John Dunlap *CTO | Lariat * *Direct:* *j...@lariat.co * *Customer Service:* 877.268.6667 supp...@lariat.co
