add config.threadsafe! #770
Conversation
|
As far as I know, our code could not be farther away from being thread safe. Thus, we deploy everything using multiple processed (and not threads) anyway. After reading through the blog post from tenderlove and this github pull request, I think it is a good idea to set However, this change also affects code loading and we should definitely give this a good test before merging (I do not feel confident enough to foresee everything this might affect). |
It is too hard to run travis on forked branches. It disturbs pull request process.
|
since we are running our deployments with multiple processes, it should probably be ok to set threadsafe! but i don't think it's a good idea. i think the opposite would be a more appropriate solution: since our code is not thread-safe we should mark it as such. especially in preparation for rails 4 when it becomes the default and we might forget about it then. |
|
As far as I understand the blog post, this disables class reloading, which I assume it also does in development mode. Since OpenProject is not thread-safe, I'd find it a bit strange to call a method saying so. If Rails 4 does this by default, we could figure out what to do then. We still wouldn't give anyone the impression of being thread-safe while we're not. Closing the pull request for now, if we nevertheless want to do this, we should create a PR not changing travis.yml. |
No description provided.