Rails 2.2 auto source code reloading broken when using config.threadsafe!

There are 2 separate issues here:

1) Threadsafe development environment not supported:

Why is threadsafe development environment not supported? Technically, it can be implemented, right? What is it in Rails that prevents us from supporting threadsafe reloading of classes? I see that you marked the bug as wontfix. Is this because the problem cannot be solved? Or is it because it is not worth solving and would involve too much time?

There is NO indication anywhere that the above is not supported. There is no documentation saying this is not supported. Nor are any errors or warnings displayed when threadsafe! is configured in development mode. At the VERY LEAST, you should put a warning in the console saying that you have threadsafety disabled and are running in dev mode.

We spent several hours tracking this bug down and it was very frustrating. A simple message somewhere would have saved us a lot of time. I'm sure that this is probably going to come up more and more often as more people move over to 2.2 threadsafe code, and definitely are going to want to test their code in a threadsafe development mode.

2) Intentionally disabling class reloading for development mode is AGAINST the whole spirit of Ruby on Rails. Why was this solution implemented? Think about it... every time I make any change in a view, model, controller, etc. I have to restart the server. The whole idea of rapid development and DRY.. well throw that out the window because everytime I make even the most minute change, I have to restart the server.

I would much rather have threadsafety ALWAYS disabled in development mode and keep class reloading than the other way around.

Joseph Chen, it is not implemented because it cannot be implemented. Thread-safety is fundamentally incompatible with class reloading. Asking for a thread-safe environment that also supports class reloading is like asking a person to hold a speech while chewing on food. It cannot be done.

But you have a point: if it cannot be supported, Rails should at least output a warning when one tries to do both. It should also be documented.

The core point also being that running something in a thread-safe environment is a performance optimization technique. It doesn't matter for development mode. Just like you don't run with class caching turned on either.

Thank you Hongli and DHH for the explanations.

DHH - I agree with you that in general, running in thread-safe mode is more of a performance optimization, like caching. But there are always exceptions to this - at times, I have enabled caching in development mode to try to track down an issue that we suspected was caused by having caching turned on.

But never mind about caching, that's a separate issue... we have a few reasons why we had enabled threadsafe mode in development:

1) We were working with DataFabric's ActiveRecord sharding plugin and after we ran into some difficulty setting it up, we wanted to make sure that the plugin worked with ActiveRecord 2.2. The plugin involves thread local storage and thread pooling when running under ActiveRecord 2.2, and not knowing what the problem was, we were trying to debug the issue. Thinking that maybe this might have something to do with threadsafety, we enabled the flag while debugging.

2) We were interested in using JRuby and had read about the benefits of having threadsafe turned on for JRuby. I would imagine that most users of Rails under JRuby would want to have the threadsafety turned on by default in development mode.

3) We were not aware of any drawbacks to having threadsafety turned on in development mode. In general, I think that having the development environment match up to the production environment as closely as possible without significantly impacting productivity is a good practice because then you can catch things that might come up in production earlier. In our case, if there are no drawbacks, then why not enable it? In retrospect, had there been some documentation or warning about not enable this feature in development mode, we would not have done this.

I added some documentation to be more explicit about this in the docrails project. It'll merge back to core rails, and show up on the Rails Guides site, presently.