Threads vs script/runner

Rails
1

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.

2

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

3

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

4

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

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