perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Dunlap <J...@lariat.co>
Subject Re: HTTP and MPM support
Date Tue, 29 Jan 2019 21:53:58 GMT
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 <narbey@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.deighan@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 <mark@blackmans.org> wrote:
>>
>>>
>>>
>>> > On 28 Jan 2019, at 23:00, Paul B. Henson <henson@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:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

Mime
View raw message