Rob,
Your repsonse is most apreciated. After having the "bug" open for such a
long time, I'm glad it's acknolwedged that it isn't thread safe. I'm not
sure with my knowledge of ithreads, I could write a patch, but I do know
that after one is written many will rejoyce. Currently, this leaves the
mod_perl Catalyst folks in a bind, using the higher perf. build of Apache2
results in a lower performance version of a Cache (file-based) while using
the better cache requires the lower perf. build of Apache2.
Unitl the day of the next version, I would suggest this be added as a
makeshift or something of the like to eliminate any confusion on the
end-user.
sub CLONE { die __PACKAGE__ . 'does not support threads' }
Thanks again, I look forward to the new version,
Evan
On 4/3/07, via RT <bug-Cache-FastMmap@rt.cpan.org> wrote:
Show quoted text>
>
> <URL:
http://rt.cpan.org/Ticket/Display.html?id=21242 >
>
> > reproducible to date, on any Apache2-mpm-worker install w/
> Cache::FastMmap
>
> Ah, I just checked. I hadn't realised that mpm was a
> multi-process/multi-threaded hybrid.
>
> Cache::FastMmap does not natively support a multi-threaded environment
> at the moment. If you're so inclined, you could hack in your own CLONE
> sub so that it reopens the cache file anew in the cloned thread, but
> otherwise the current way perl clones objects when creating threads will
> result in a double free when it tries to clean up.
>
> If you have a patch to make it work I'll look at adding it back, but for
> now all I'm going to do is add a note in the next version that it's not
> thread safe.
>
> Rob
>
>
--
Evan Carroll
System Lord of the Internets
832-445-8877