At 10:35 AM +0300 10/22/08, Aliaksey Kandratsenka wrote: >ì Ä Ú, 21/10/2008 Û 23:46 -0700, rogerdpack Ô¥¯ý: >> > > Reloading isn'tthreadsafeand *can't* be due to the way constant >> > > definition works in ruby. Why are you doing it in production mode? >> > > allow_concurrency should be false for development mode? Is itnot? >> >> I'm curious about the "constant definition not being threadsafe" -- is >> this a thread safe bug in MRI? >> >One of the problems here is that the class which is being defined is >visible in other threads. So threads may see partially defined classes. >This is very hard to fix. And it's indeed ruby's (not just MRI, I >believe) problem. > >In MRI it is possible to stop all other threads (by setting >Thread.critical) and Rails could try to solve this problem by holding >this flag around #load and #require. But this is not a proper solution, >because Thread.critical is implementation-specific feature and sooner or >later ruby will need to get rid of it. And it should be noted that even >this solution may fail if fancy things is tried during load. For example >if it tries to lock some mutex, which is locked by some other thread.
fyi: Here's a pointer to a recent thread among the jruby developers about a similar issue: 'require' thread safety? http://www.nabble.com/%27require%27-thread-safety--td19988160.html#a19988160 Basically what should require do when the same library is loaded by two or more threads? The problem is that after the first "require 'mylib'" starts (but before it has finished evaluating the code) what should ruby do when a script in a second thread evaluates: "require 'mylib'". They decided to: 2. synchronize against the list of loaded features, such that they may both search for the library but only one will load it; however, this won't guarantee the library has been *completely* loaded At 12:49 PM -0500 10/16/08, Charles Oliver Nutter wrote: >I think there's a strong argument that you have no guarantee after calling >require and receiving "false" that the library has *completed* loading, only >that someone else has *initiated* a load. It's certainly a bad pattern to be >doing requires in many threads, and I don't personally believe there's any >level of locking or synchronization that would safely guarantee a require >that's started has completed before someone tries to use the code in that >library. > >I'd love to be proven wrong, but all the scenarios and solutions proposed so >far to cause a require to block are certainly going to be deadlock-prone. I >think our best be now is definitely (2), to at least guarantee that a given >library can't be require'd twice, even if we can't guarantee across threads >that once require returns false the target library is ready for use. --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
