> I think it's an achievable feat too, but I'm a little hesitant to > just whack mutexes everywhere we find a race condition. Instead I'd > like to think a little more about the changes which are needed to make > the thing work and rejig the internals to make the task simpler.
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. > I'd suggest a candidate first-task is tidying up the ActiveRecord > allow_concurrency stuff to use a connection pool rather than blindly > establishing a connection per thread. This would require some pretty On ActiveRecord, I think it's great that people want to improve it. But personally I want to focus on the parts of rails which are not yet thread safe. AR is at least somewhat thread-safe already. Of course I have no problem with anyone else working on it :) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
