# Threads vs script/runner

**URL:** <https://www.ruby-forum.com/t/threads-vs-script-runner/49095>\
**Category:** Rails\
**Created:** [November 29, 2005, 8:16pm UTC](https://www.ruby-forum.com/t/threads-vs-script-runner/49095 "2005-11-29T20:16:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![kyle](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/848f3c/32.png) [@kyle](https://www.ruby-forum.com/u/kyle)\
**Post date:** [November 29, 2005, 8:16pm UTC](https://www.ruby-forum.com/t/threads-vs-script-runner/49095/1 "2005-11-29T20:16:16Z")

</div>

I am currently running some background processes by using  
script/runner to run an infinite loop (with a sleep). I am  
considering moving this to a thread that is forked off of the  
environment file. This would be easier to maintain, because I  
wouldn’t have to start and stop it independently of my rails app. I  
was wondering: Does anyone knows any more pros and cons of this  
comparison?

Thanks!  
Kyle M.

---

<div class="post-metadata">

**Author:** ![kyle](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/848f3c/32.png) [@kyle](https://www.ruby-forum.com/u/kyle)\
**Post date:** [November 29, 2005, 8:28pm UTC](https://www.ruby-forum.com/t/threads-vs-script-runner/49095/2 "2005-11-29T20:28:24Z")

</div>

Wouldn’t it be far better to set up a cron process that starts the  
background  
script/runner script on the period that you want? That would seem to be  
orders  
of magnitude more efficient than running an infinite loop…

-Brian

---

<div class="post-metadata">

**Author:** ![kyle](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/848f3c/32.png) [@kyle](https://www.ruby-forum.com/u/kyle)\
**Post date:** [November 29, 2005, 8:40pm UTC](https://www.ruby-forum.com/t/threads-vs-script-runner/49095/3 "2005-11-29T20:40:34Z")

</div>

The startup costs of script/runner are not insignificant, so a loop with  
a sleep  
is nice for the CPU costs, but probably harder to maintain.

Regards,  
Blair

---

<div class="post-metadata">

**Author:** ![kyle](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/848f3c/32.png) [@kyle](https://www.ruby-forum.com/u/kyle)\
**Post date:** [November 30, 2005, 8:15am UTC](https://www.ruby-forum.com/t/threads-vs-script-runner/49095/4 "2005-11-30T08:15:33Z")

</div>

Kyle,

The biggest problem with what you want is that normal Rails runs fairly  
stateless, especially as a CGI. With a CGI you’ll never get it to  
work. I believe it’ll work in WEBrick, but I remember that WEBrick  
seemed to also kill off threads like Rails was a CGI.

Under FastCGI or SCGI you could probably do it since they are long  
running processes, but you’ll have to setup your thread(s) outside of  
the Rails control, most likely with a global or similar (Singleton?)  
unique place.

Another option–if you need better control from your Rails  
application–is to create a simple DRb API to your stand-alone  
processor. This kind of gives you the best of all worlds.

The finaly problem I _know_ you’ll run into is if this processor is  
supposed to be unique on a machine–where only one runs–then you’ll  
have huge problems in a clustering situation. Imagine it this way:  
You have your wonderful processor thread working great with 1 SCGI  
process. Now, you decide to speed up your app and start 4 SCGI  
processor, which also means you have 4 of your little processing  
threads running.

In this situation, look to the DRb solution or just a simple cronjob.

Zed A. Shaw

> **[Zed A. shaw](https://zedshaw.com/)**
>
> Personal essays and writings by Zed A. Shaw.

On Tue, 29 Nov 2005 11:14:34 -0800