<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.1" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Writing a standlone, threaded application using Ruby On Rails</title>
	<link>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/</link>
	<description>Real world talk about web design, programming and the business of web design.</description>
	<pubDate>Mon, 13 Oct 2008 02:03:48 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.1</generator>
		<item>
		<title>By: M.sivakrishna</title>
		<link>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/#comment-155681</link>
		<dc:creator>M.sivakrishna</dc:creator>
		<pubDate>Wed, 14 May 2008 03:02:26 +0000</pubDate>
		<guid>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/#comment-155681</guid>
		<description>t = Thread.new do &#124;&#124;
10.times do &#124;i&#124;
puts "A#{i}"
sleep 1
end
stop
end

t1 = Thread.new do &#124;&#124;
10.times do &#124;i&#124;
puts "B#{i}"
sleep 1
end
stop
end

4.times do &#124;i&#124;
puts "** Parent #{i}"
sleep 2
end
stop
t.join
t1.join</description>
		<content:encoded><![CDATA[<p>t = Thread.new do ||<br />
10.times do |i|<br />
puts &#8220;A#{i}&#8221;<br />
sleep 1<br />
end<br />
stop<br />
end</p>
<p>t1 = Thread.new do ||<br />
10.times do |i|<br />
puts &#8220;B#{i}&#8221;<br />
sleep 1<br />
end<br />
stop<br />
end</p>
<p>4.times do |i|<br />
puts &#8220;** Parent #{i}&#8221;<br />
sleep 2<br />
end<br />
stop<br />
t.join<br />
t1.join</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon McCartney</title>
		<link>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/#comment-118395</link>
		<dc:creator>Simon McCartney</dc:creator>
		<pubDate>Sun, 30 Dec 2007 17:53:06 +0000</pubDate>
		<guid>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/#comment-118395</guid>
		<description>Your comments about single requests and webrick &#38; mongrel are valid, it be can somewhat limiting frustrating. I've used both Apache with Mongrel clusters (in a proxy/cluster/balancer setup) and lighttpd/FastCGI, I found the lighttpd/fcgi method much simpler &#38; straight forward, even though I've 5+ years of mucking about with Apache.

It's very easy to setup a small environment that can support multiple requests, spawning more processes to handle further requests.  I normally end up dropping a lighttpd.conf into config/ so it's nice and easy when moving from your development box to test/production.</description>
		<content:encoded><![CDATA[<p>Your comments about single requests and webrick &amp; mongrel are valid, it be can somewhat limiting frustrating. I&#8217;ve used both Apache with Mongrel clusters (in a proxy/cluster/balancer setup) and lighttpd/FastCGI, I found the lighttpd/fcgi method much simpler &amp; straight forward, even though I&#8217;ve 5+ years of mucking about with Apache.</p>
<p>It&#8217;s very easy to setup a small environment that can support multiple requests, spawning more processes to handle further requests.  I normally end up dropping a lighttpd.conf into config/ so it&#8217;s nice and easy when moving from your development box to test/production.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kalugen</title>
		<link>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/#comment-80012</link>
		<dc:creator>Kalugen</dc:creator>
		<pubDate>Thu, 19 Jul 2007 16:18:15 +0000</pubDate>
		<guid>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/#comment-80012</guid>
		<description>Yes it is.

In the version without the final "joins" the main thread exits and the children do not have time to finish their processing. Put a longer "sleep" there and see...

If you want this kind of behaviour, with the parent going on doing its biddings (but not necessarily for as long as it takes for the children to finish their job), then I think you *have* to use something more similar to what fork() does in *NIX (particularly, look for what happens when you ignore CHLD signals).

As far as I understand, Ruby's threads are not ment to survive their parent.</description>
		<content:encoded><![CDATA[<p>Yes it is.</p>
<p>In the version without the final &#8220;joins&#8221; the main thread exits and the children do not have time to finish their processing. Put a longer &#8220;sleep&#8221; there and see&#8230;</p>
<p>If you want this kind of behaviour, with the parent going on doing its biddings (but not necessarily for as long as it takes for the children to finish their job), then I think you *have* to use something more similar to what fork() does in *NIX (particularly, look for what happens when you ignore CHLD signals).</p>
<p>As far as I understand, Ruby&#8217;s threads are not ment to survive their parent.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: roger pack</title>
		<link>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/#comment-75806</link>
		<dc:creator>roger pack</dc:creator>
		<pubDate>Fri, 06 Jul 2007 15:59:13 +0000</pubDate>
		<guid>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/#comment-75806</guid>
		<description>Note that if the 'main' thread exits then all existing [still running] threads will be insta terminated.  Maybe that's a factor.</description>
		<content:encoded><![CDATA[<p>Note that if the &#8216;main&#8217; thread exits then all existing [still running] threads will be insta terminated.  Maybe that&#8217;s a factor.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Mischook</title>
		<link>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/#comment-58737</link>
		<dc:creator>Richard Mischook</dc:creator>
		<pubDate>Sun, 20 May 2007 22:33:41 +0000</pubDate>
		<guid>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/#comment-58737</guid>
		<description>My use of join was based on examples picked elsewhere. I have just been reviewing the API and the only other method I can find that one might use to start a thread is run. Alas it is not really working as start() does in Java. In fact take the following:

t = Thread.new do &#124;&#124;
  10.times do &#124;i&#124;
    puts "A#{i}"
    sleep 1
  end
end

t1 = Thread.new do &#124;&#124;
  10.times do &#124;i&#124;
    puts "B#{i}"
    sleep 1
  end
end

If I run that I get the following output:

A0
B0

If I add the following lines:

t.join
t1.join

I get:

A0
B0
A1
B1
B2
A2
A3
B3
B4
A4
A5
B5
B6
A6
A7
B7
B8
A8
A9
B9

Strangely enough if I remove the join lines and instead add:

10.times do &#124;i&#124;
  puts "** Parent #{i}"
  sleep 1
end

I get:

A0
B0
** Parent 0
A1
** Parent 1
B1
A2
** Parent 2
B2
** Parent 3
B3
A3
B4
A4
** Parent 4
A5
** Parent 5
B5
** Parent 6
B6
A6
B7
A7
** Parent 7
A8
** Parent 8
B8
** Parent 9
B9
A9

This is not what I would expect although the parent does continue and is switched with the other threads. But if I reduce the parent loop from 10 to say 3, then as soon as the 3 loop is complete the kid threads die - unless I add the join lines after the parent loop. In other words without a join, the kid threads do not seem to have a life of their own once the parent thread has finished going about it's business.

So the final code I end up with, which allows the kids to live on is as below. You are correct though insofar as this code does allow the parent thread to keep on processing in parallel with the kids.

t = Thread.new do &#124;&#124;
  10.times do &#124;i&#124;
    puts "A#{i}"
    sleep 1
  end
end

t1 = Thread.new do &#124;&#124;
  10.times do &#124;i&#124;
    puts "B#{i}"
    sleep 1
  end
end


3.times do &#124;i&#124;
  puts "** Parent #{i}"
  sleep 1
end

t.join
t1.join</description>
		<content:encoded><![CDATA[<p>My use of join was based on examples picked elsewhere. I have just been reviewing the API and the only other method I can find that one might use to start a thread is run. Alas it is not really working as start() does in Java. In fact take the following:</p>
<p>t = Thread.new do ||<br />
  10.times do |i|<br />
    puts &#8220;A#{i}&#8221;<br />
    sleep 1<br />
  end<br />
end</p>
<p>t1 = Thread.new do ||<br />
  10.times do |i|<br />
    puts &#8220;B#{i}&#8221;<br />
    sleep 1<br />
  end<br />
end</p>
<p>If I run that I get the following output:</p>
<p>A0<br />
B0</p>
<p>If I add the following lines:</p>
<p>t.join<br />
t1.join</p>
<p>I get:</p>
<p>A0<br />
B0<br />
A1<br />
B1<br />
B2<br />
A2<br />
A3<br />
B3<br />
B4<br />
A4<br />
A5<br />
B5<br />
B6<br />
A6<br />
A7<br />
B7<br />
B8<br />
A8<br />
A9<br />
B9</p>
<p>Strangely enough if I remove the join lines and instead add:</p>
<p>10.times do |i|<br />
  puts &#8220;** Parent #{i}&#8221;<br />
  sleep 1<br />
end</p>
<p>I get:</p>
<p>A0<br />
B0<br />
** Parent 0<br />
A1<br />
** Parent 1<br />
B1<br />
A2<br />
** Parent 2<br />
B2<br />
** Parent 3<br />
B3<br />
A3<br />
B4<br />
A4<br />
** Parent 4<br />
A5<br />
** Parent 5<br />
B5<br />
** Parent 6<br />
B6<br />
A6<br />
B7<br />
A7<br />
** Parent 7<br />
A8<br />
** Parent 8<br />
B8<br />
** Parent 9<br />
B9<br />
A9</p>
<p>This is not what I would expect although the parent does continue and is switched with the other threads. But if I reduce the parent loop from 10 to say 3, then as soon as the 3 loop is complete the kid threads die - unless I add the join lines after the parent loop. In other words without a join, the kid threads do not seem to have a life of their own once the parent thread has finished going about it&#8217;s business.</p>
<p>So the final code I end up with, which allows the kids to live on is as below. You are correct though insofar as this code does allow the parent thread to keep on processing in parallel with the kids.</p>
<p>t = Thread.new do ||<br />
  10.times do |i|<br />
    puts &#8220;A#{i}&#8221;<br />
    sleep 1<br />
  end<br />
end</p>
<p>t1 = Thread.new do ||<br />
  10.times do |i|<br />
    puts &#8220;B#{i}&#8221;<br />
    sleep 1<br />
  end<br />
end</p>
<p>3.times do |i|<br />
  puts &#8220;** Parent #{i}&#8221;<br />
  sleep 1<br />
end</p>
<p>t.join<br />
t1.join</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: gc</title>
		<link>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/#comment-58729</link>
		<dc:creator>gc</dc:creator>
		<pubDate>Sun, 20 May 2007 21:21:00 +0000</pubDate>
		<guid>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/#comment-58729</guid>
		<description>About your problem with Ruby threads and your claim that the parent thread must wait for all kiddy threads to finish before proceeding: I think you're misunderstanding how threads should be used. You're "joining" every threads you've created; have you looked at what #join is supposed to do? Just like in Java actually: it waits for the specified Thread to die. What was your point in joining all your created threads? Just forget about joining threads, and they'll live their life just like Java threads...</description>
		<content:encoded><![CDATA[<p>About your problem with Ruby threads and your claim that the parent thread must wait for all kiddy threads to finish before proceeding: I think you&#8217;re misunderstanding how threads should be used. You&#8217;re &#8220;joining&#8221; every threads you&#8217;ve created; have you looked at what #join is supposed to do? Just like in Java actually: it waits for the specified Thread to die. What was your point in joining all your created threads? Just forget about joining threads, and they&#8217;ll live their life just like Java threads&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Mischook</title>
		<link>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/#comment-16870</link>
		<dc:creator>Richard Mischook</dc:creator>
		<pubDate>Wed, 24 Jan 2007 14:17:26 +0000</pubDate>
		<guid>http://www.killersites.com/blog/2007/standalone-ruby-on-rails/#comment-16870</guid>
		<description>In the blog I mentioned that I had some issues packaging up the application using the tools at http://www.erikveen.dds.nl/distributingrubyapplications/rails.html. I contacted the author who was very helpful in pointing out my mistake (which I won't specify here 'cause it makes me look really bad). With his help I have been able to package the whole thing up into a standalone windows .exe which is kind of cool.

I am now working on a new version that addresses some of the issues I raised in the blog and will report back as I make progress.</description>
		<content:encoded><![CDATA[<p>In the blog I mentioned that I had some issues packaging up the application using the tools at <a href="http://www.erikveen.dds.nl/distributingrubyapplications/rails.html." rel="nofollow">http://www.erikveen.dds.nl/distributingrubyapplications/rails.html.</a> I contacted the author who was very helpful in pointing out my mistake (which I won&#8217;t specify here &#8217;cause it makes me look really bad). With his help I have been able to package the whole thing up into a standalone windows .exe which is kind of cool.</p>
<p>I am now working on a new version that addresses some of the issues I raised in the blog and will report back as I make progress.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
