deepak

This example shows how to setup an environment running Rails 3 beta under 1.9.1 with a 'rails3' gem set.

∴ rvm update --head
# ((Open a new shell)) or do 'rvm reload'

# If you do not already have the ruby interpreter installed, install it:
∴ rvm install 1.9.1

# Switch to 1.9.1 and gemset rails3, create if it doesn't exist. 
∴ rvm --create use 1.9.1@rails3

deepak

require 'rubygems'
require 'mysql'

# thanks to piyush_ in irc.

# mysql blocks the ruby interpreter
# alternatives:
# 1) use neverblock/mysqlplus mysql driver.
# 2) use jruby - will use java threads.
# 3) postgres driver does not block.

deepak

# usage: ruby thread_simple.rb
thread1 = Thread.new {
  while(true) do 
    print '*'
    sleep 0.1
  end
}

# if we set sleep the print never gets executed even after waiting for
# 5 seconds. WTF!!! 

deepak

counter=0
threads = []
while true
  t = Thread.new{
    sleeping = counter
    puts "Sleeping for #{sleeping} seconds"
    sleep sleeping
    puts "Woke up from #{sleeping} seconds sleep"
  }
  threads << t

deepak

require 'rubygems'
require 'do_mysql'

# thanks to jeremyevans, he says:
# do_* drivers are async - uses rb_thread_select c-api call to manage
# threads.

# check if this code has been pushed upstream to the mysql library
# also see http://gist.github.com/356250 for plain mysql

deepak

>  - In ruby 1.8.x, what is the functional difference between rb_thread_schedule and rb_thread_select?

rb_thread_schedule() is the guts of the thread scheduler, it traverses
over the linked list of threads (several times) to find the next one
to switch into. The function is long (250 lines) and messy, and covers
all the combinations of thread status (RUNNABLE, TO_KILL, STOPPED,
KILLED) and wait state (FD, SELECT, TIME, JOIN, PID).

If there are no threads doing i/o or waiting on a timeout,
rb_thread_schedule() picks another thread from the list (considering

deepak

DB = Sequel.mysql(:host => db_config["host"],
             :user => db_config["username"],
             :password => db_config["password"],
             :database => db_config["database"],
             :encoding => db_config["encoding"],
             :max_connections => 1,
             :compress => true,
             :single_threaded => true)

DB.disconnect

deepak

DB = Sequel.mysql(:host => db_config["host"],
             :user => db_config["username"],
             :password => db_config["password"],
             :database => db_config["database"],
             :encoding => db_config["encoding"],
             :max_connections => 1,
             :compress => true,
             :single_threaded => true)

DB.disconnect

deepak

# Oleg Andreev <oleganza@gmail.com> Oct 16, 2009
#
# This demonstrates how to perform a request to the same Rails instance without hitting HTTP server.
# Note 1: this does not boot another Rails instance
# Note 2: this does not involve HTTP parsing
# Note 3: dispatch_unlocked and rack.multithread=true are used to prevent deadlock on a dispatch mutex,
#         NOT to make inner requests operate concurrently as one may think.
# Note 4: inner request is created by merging outer request with some HTTP headers and rack options.
#         This may probably lead to strange effects, so be aware of it. 
#         Perhaps, we shouldn't use outer request at all. I don't know.

deepak

#
# Created by Eric Lindvall <eric@sevenscale.com>
#
# WHAT: Provides a simple overview of memory allocation occuring during a
# require.
#
# For a longer explanation, see my post at:
#
# http://bitmonkey.net/post/308322913/tracking-initial-memory-usage-by-file-in-ruby
#