NSProgress with Asynchronous Tasks

Use NSProgress to bind your UI with the progress of asynchronous tasks.

Singletons, Threads, and Flexibility

January 18, 2013

In Ruby, we often like very simple APIs, but this often comes at the price of thread safety and code flexibility. I’ve found that if you use a few tricks from the start, you can get the best of it all.

I recently did a project where I tried to use the VCR gem, but it went awry when working in multiple threads. This is a great gem that, like many of my own, falls into the trap of module/class level singleton configuration/execution.

This approach is characterized by things like extend self in the top-level module and then having instance variables at that level. This is not to call out VCR specifically. it’s just my most recent example of hundreds of gems that take this overall approach.

module VCR
  extend self

  def current_cassette
    cassetes.last
  end

  def configure
    yield configuration
  end

  def configuration
    @configuration ||= Configuration.new
  end

  private

  def cassettes
    @cassettes ||= []
  end
end

When operating on multiple threads, things get wacky because they are sharing this current_cassette and writing to the associated file. You end up with recordings on top of each other.

I am inclined (and some say over-inclined) to use singletons to do something like this:

class VCR::Client
  def current_cassette
    cassetes.last
  end

  def configure
    yield configuration
  end

  def configuration
    @configuration ||= Configuration.new
  end

  private

  def cassettes
    @cassettes ||= []
  end
end

module VCR
  extend self

  delegate :current_cassette, :configure, :configuration, :to => :default_client

  def default_client
    @default_client ||= Client.new
  end
end

The most common use case of the module doesn’t change at all because I delegate everything to a default one. You can still do:

# global
VCR.configure do |c|
  c.cassette_library_dir = 'fixtures/vcr_cassettes'
end

class Fetcher
  def initialize(path)
    @path = path
  end

  def fetch!
    VCR.use_cassette('#{@path}/fetched') do
      response = Net::HTTP.get_response(URI("api.http://example.com/#{@path}"))
      process(response)
    end
  end
end

class Main
  def process_all
    self.paths.each do |path|
      fetcher = Fetcher.new(path)
      fetcher.fetch!
    end
  end
end

and it will use the default_client.

But this whole scheme now allows my threaded code to do something like this:

class ThreadedFetcher
  def initialize(path)
    @path = path
  end

  def vcr_client
    return @vcr_client if @vcr_client
    @vcr_client = VCR::Client.new
    @vcr_client.configure do |c|
      c.cassette_library_dir = "fixtures/vcr_cassettes/#{@path}"
    end
    @vcr_client
  end

  def fetch!
    # the same original code would probably work but I like it even more separated 
    # that is, move the @path into client init above
    vcr_client.use_cassette('fetched') do
      response = Net::HTTP.get_response(URI("http://api.example.com/#{@path}"))
      process(response)
    end
  end
end

class Main
  def process_all
    mutex = Mutex.new
    queue = self.paths.dup

    self.thread_count.times.map {
      Thread.new do
        while path = mutex.synchronize { queue.pop }
          fetcher = ThreadedFetcher.new(path)
          fetcher.fetch!
        end
      end
    }.each(&:join)
  end
end

Clearly there’s more code, but it is now 8x (or whatever) faster.

One example that I’ve seen done really well in this way is the twitter gem and others that seems to follow that pattern like octokit which I used for hubtime in such a threaded way.

Again, I’m not calling out VCR or anything and I’m sure I’ve trivialized the complexity involved. I would love to pull a pull request link to VCR here, but alas, for another time.

If you do this from the beginning, though, it can be a strong win with minimal overhead. It adds multi-threaded capabilities as well as the ability (such as with Twitter) to work with two different users in your app without changing anything global.

[…]

The Ruby Rails Aggregator