Thread safety

[MmKolodziej]

Overall, thread safety is really a big issue in this gem. Which, you could argue is "okish", since fails can be returned only when one of racing checks returns a false.

I've only been using a few checks and I've noticed a rather big issue with GenericCacheCheck though. When 2 checks hit a multi threaded application, the values saved in the key shared by both threads will be random, which will very likely cause a fail when reading them back. I am solving this temporarily with a mutex, since I am not sure whether you'd prefer to generate a more unique key (which could potentially lead to things being left over in a cache store) or a mutex.

[pbyrne]

I'll admit that thread safety really hasn't been something I've paid much attention to with this gem, since I primarily use Uncorn (process-based vs thread-based). Mutexes feel reasonable to me as a moderate-impact solution with the way the app is written now.

Rewriting the engine to instantiate fresh instances of the checks with each request also feel reasonable (and would also eliminate some of the grossness around clearing state when starting a new set of checks). It's unclear to me how tough that would be to accomplish in a backward-compatible way.

[johnnyshields]

This should be in-scope for 2.0