Rails core - Jul 2010 - non auto load in concurrency

I am under the impression that if config.threadsafe! was set that it
preloaded all files in the require paths, instead of using autoload.

Suggestion: use autoload when threadsafe!, but with a wrapper, like

autoload :Command,            ''thin/command''

becomes

autoload :Command, ''wrappers/
file_that_loads_command_but_in_a_mutex.rb''

Then it might avoid loading unused dependencies in production, thus
saving on RAM and GC times.
Thoughts?
-r

-- 
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
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Unfortunately, simply requiring the files in a mutex won''t work.
Consider
the following simplified example:

# person.rb
class Person
  sleep 10

  def say_hello
    puts "Hello"
  end
end

# mutexed autoloads
def const_missing(klass)
  @mutex.synchronize do
    require autoload[klass]
  end
end

# usage
Thread.new do
  # this will trigger person.rb, which will immediately make Person
available, but
  # not add say_hello
  Person.say_hello
end

Thread.new do
  # Person is already created, so the const_missing will not fire (or
autoload, etc.)
  # but say_hello is not yet defined
  Person.say_hello
end

Yehuda Katz
Architect | Engine Yard
(ph) 718.877.1325


On Sat, Jul 3, 2010 at 10:43 AM, rogerdpack <rogerpack2005@gmail.com>
wrote:
> I am under the impression that if config.threadsafe! was set that it
> preloaded all files in the require paths, instead of using autoload.
>
> Suggestion: use autoload when threadsafe!, but with a wrapper, like
>
> autoload :Command,            ''thin/command''
>
> becomes
>
> autoload :Command, ''wrappers/
> file_that_loads_command_but_in_a_mutex.rb''
>
> Then it might avoid loading unused dependencies in production, thus
> saving on RAM and GC times.
> Thoughts?
> -r
>
> --
> 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
>
rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
-- 
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
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On Jul 3, 2:11 pm, Yehuda Katz <wyc...@gmail.com>
wrote:
> Unfortunately, simply requiring the files in a mutex won''t work.
Consider
> the following simplified example:
>
> Thread.new do
>   # Person is already created, so the const_missing will not fire (or
> autoload, etc.)
>   # but say_hello is not yet defined
>   Person.say_hello
> end
Interesting.  I suppose you''d have to somehow restrict it, which is
probably impossible. Ok, thanks for your feedback.
-r

-- 
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
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.