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 <nar...@gmail.com> 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 <john.deig...@gmail.com> > 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 <m...@blackmans.org> wrote: >> >>> >>> >>> > On 28 Jan 2019, at 23:00, Paul B. Henson <hen...@acm.org> 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 <j...@lariat.co>* *Customer Service:* 877.268.6667 supp...@lariat.co
