rtomayko / tilt

Generic interface to multiple Ruby template engines

Home Page:http://github.com/rtomayko/tilt

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Make Tilt::Cache thread-safe

kushkella opened this issue · comments

Right now Tilt::Cache is just a hash. It returns the value if present, otherwise stores the value and then returns it. This behavior is not thread-safe and makes Tilt::Cache unusable in multi-threaded environment. I think we should implement something like this https://github.com/rails/rails/blob/714a38217e884418d635435eb658ae7347d08dd7/activesupport/lib/active_support/cache/memory_store.rb

I'm not saying that we should add all the pruning and add TTLs but while storing and retrieving objects, we should use a lock to make sure the operation is thread safe. Thanks!

I think this generally solves the issue. Any updates?

I'm hesitant to change an API that has never been thread-aware:

  1. Those who care about threading issues have already added a Mutex. Another Mutex could cause performance issues.
  2. Tilt::Cache has always been a very simple API to show how you can add template caching. I don't want it to be a fully-featured caching API; everyone has different constraints and use-cases.

Thoughts?

My thought would be either to get rid of it or at least document its
deficiencies so people don't get suckered into using it: it's not
thread-safe, it's size isn't bounded, the keys should not be mutated;
anything else?

On Mon, Jul 6, 2015 at 2:01 AM, Magnus Holm notifications@github.com
wrote:

I'm hesitant to change an API that has never been thread-aware:

  1. Those who care about threading issues have already added a Mutex.
    Another Mutex could cause performance issues.
  2. Tilt::Cache has always been a very simple API to show how you can
    add template caching. I don't want it to be a fully-featured caching API;
    everyone has different constraints and use-cases.

Thoughts?


Reply to this email directly or view it on GitHub
#260 (comment).

it's not thread-safe, it's size isn't bounded, the keys should not be mutated.

That's about it. I'd accept a documentation patch.

This was fixed (that is, properly documented) in #266.