From: Ken Bloom <kbloom@...>
Date: 2008-12-04T09:32:30+09:00
Subject: [ruby-core:20278] Re: autoload and concurrency

On Thu, 04 Dec 2008 06:58:54 +0900, Brent Roman wrote:

> Yes, I'd forgotten for a moment about the deadlock issue. Thanks for
> reminding me.
> 
> One way to avoid the deadlocks might be to dedicate a thread to
> servicing all requests to load new code.  Require and constant
> resolution with "autoload" enabled would be redefined to queue code load
> requests.   The code "loader" thread would remove such requests from the
> queue, then load the required ruby files (including other files required
> by the requested file) while the requesting thread waited remained
> blocked. The loader thread would release the requesting thread only
> after
>  its require request had been satisfied.
> 
> This single code loader thread thus serializes the otherwise ill behaved
> concurrent Ruby code loading.
> 
> There are some details I'm (knowingly) omitting. Does anyone see any
> truck sized holes in this general idea?

Loading code right now is a depth-first search of the dependency tree for 
the required file. Your suggestion would change it to a breadth first 
search. As a result, the following example would try to inherit from Bar 
before Bar was defined, something that is not the case now. If you extend 
that to Kernel#require and not just Kernel#autoload, as you say, then 
most currently existing Ruby code would break because of this.

$ cat a.rb
Kernel.autoload(:Foo,'b')
Foo.something

$ cat b.rb
Kernel.autoload(:Bar,'c')
class Foo < Bar
  def self.something
    puts "FizzBang"
  end
end

$cat c.rb
class Bar
end


-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/