Some person says:
Never used them myself, but [....] Cache::FastMmap says:
[...] ensure multiple processes [...]
so it should certainly be thread-safe.
Meanwhile, Cache::FastMmap itself reports:
Cache::FastMmap does not support threads.
Which source do you think is most likely to be correct? :)
To add some context and/or clarity... Looking at the source code, FastMmap.pm, one finds:
sub CLONE {
die "Cache::FastMmap does not support threads sorry";
}
Searching perlmod for "CLONE" we find that this sub is called after a Perl thread is created.
So Cache::FastMmap clearly declares itself to not support Perl threads and that error message appearing as reported seems to indicate that Perl inside of Apache is actually creating Perl threads.
My experience is that Apache doesn't create Perl threads by default nor in the vast majority of configurations of Apache that I've run into.
So my guess at a possible short route to resolving the problem would be to modify the Apache configuration to tell it to stop spawning threads.
[ Aside:
It has been a long time since I looked at mixing Apache, Perl, and threads. But I recall finding that Apache threading made use of Perl threads. That matches a pattern I had seen elsewhere when embedding Perl into a program that uses threads. I still believe that this pattern comes about from an understandable (unless you expect people to read and understands the docs) but unfortunate misunderstanding.
If I were to embed Perl into a program that uses threads, I would very much not make use of Perl's threads. I'd certainly be at least tempted to build Perl w/o "thread support". "But how can you use Perl from threads if you build it without support for threads?" you ask.
Building Perl with support for threads is about making it possible for Perl to create threads. Using Perl from threads doesn't require that at all. When embedding Perl for use from threads, you have two choices:
First, you can use a single Perl interpreter instance (per process) and access that instance from as many threads as you like so long as only one thread at a time uses it.
Second, you can build Perl with "MUTLIPLICITY" (see perlguts) and have as many instances of the Perl interpreter as you want in your process and each can be used from any threads so long as only one thread at a time uses it. You could choose to bind each instance of the interpreter to a specific thread. That means you don't have to worry about having locks barring simultaneous use of each interpreter instance, but that also means that each thread must pay the penalty of the memory required for a full instance of Perl. For some use cases, that will make sense.
(In the first case, I would probably build Perl w/o MULTIPLICITY, though it should work even w/ MULTIPLICITY so long as you always pass in the same "context".)
Note that even a Perl module that doesn't "support threads" would likely work fine in multiple Apache threads if Apache had not made the mistake of using Perl threads. Now, there are a few things that a Perl module could do that could break in such a scenario, but I find those things to be rather unlikely in a Perl module, especially one embedded in Apache.
But fixing Apache threads to not use Perl threads is likely no small endeavor (not even counting the significant political/social tasks required). So this aside isn't particularly useful. Though, I hope some small number of people find it, to some extent, informative.
]
|