On Apr 14, 10:35 am, coderrr <[EMAIL PROTECTED]> wrote: > I agree, mutexes are not the solution for every threading problem, but > I believe for some problems they are the best (most pragmatic) > solution. There is a non mutex solution to this race condition which > is to use a unique method name for every combination of template-name/ > local-assings (currently the method name is only based on the template > name). To me this is more complex and less elegant than a mutex. > > There may be a larger reworking of template compilation that fixes > this race condition. But I don't see an issue with fixing it with a > mutex until someone takes on that task. I'd love to hear if you have > a different or better solution to this though.
Rails should compile and cache all the templates on boot. This means before any dispatch threads are even run. BTW, just adding mutexes in patch by patch isn't really going work. There is already a mutex that wraps the dispatch by mongrel and another that AP wraps the dispatch w/. (We need to drop the one in the mongrel handler). I suggest working on this stuff in a different branch (aka my thread_safe branch :) until we've got it done. I think the bigger problem is getting your app to be threadsafe. We should look into adding some helpful development features to find non threadsafe code. I added a feature to my branch that warns you if you try to modify class variables through a caccessor if it is not safe. I made a "Thread.current.safe?" that checks if you are 1) In a thread and 2) not inside a mutex. (all highly experimental!) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
