Crash about ttlcache HOT 3 CLOSED

No problem as i did'nt see the issues in the change either, but it did found some design guidelines:

• Since there are no recursive locks the locking should always be done over whole 'top-level' operations in the Cache struct
• Some parts of the code released a lock and then acquired a second one during the same operation. This is also a bad pattern as it effectively invalidates the data retrieved during the first lock.

from ttlcache.

Crash in configuration that was not explicitly tested. Configuration was added.

As it turns out the switch to RWLock was not a good one. There are data races all over the place if TTL is extended on hit. Another issue comes from

cache.expirationNotification <- true

This channel is async, but blocking and therefore can cause blocking conditions in conjunction with the locks on Get/Set calls and the cleanup routine.

All races have been fixed.

from ttlcache.

sorry to introduce instability, thanks for the fix

from ttlcache.