Forum: Ruby on Rails Independent thread use in Rails app

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
67cb6fef42a83929955ce5a5b3f33f6e?d=identicon&s=25 Jon Smirl (Guest)
on 2005-12-30 17:17
(Received via mailing list)
I would like to be able to start several independent threads in my
Rails app. These threads will run as long as the Rails app is running.

1) What is the right place to start and stop the threads? My threads
need to run shutdown  code.  I've tried adding code like this but it
isn't working correctly. The debugger is getting an ABRT or TERM
signal and I still need to shut down the database.

Signal.trap("INT") { threads[0].kill; database.close; server.shutdown}
%w{ABRT CLD TERM STOP QUIT}.each { |x| Signal.trap(x) {
database.close; server.shutdown } }

threads[0].kill this is the monitor thread, it will never exit unless
killed. Alternatively I could send it a message to exit.

2) I'd like to set things up so that if WEBrick is being used the
threads run in the same process. But if lighttpd is being used with
multiple processes the thread only gets started in one of the fastcgi
processes.  There needs to be some mechanism to see if the process
with the thread dies and get it started again in another fastcgi
process.

The thread monitors the directory tree being served, if files are
copied in or removed it add/deletes them from a search database. It is
using iNotify on Linux, but other OSes offer similar monitoring APIs.
I'll make the code public as soon as it is working, unless someone
tells me this has already been written.

--
Jon Smirl
jonsmirl@gmail.com
B554bcde846e4497eeffffc1399d3b09?d=identicon&s=25 Benjamin Stiglitz (Guest)
on 2005-12-30 18:16
(Received via mailing list)
> I would like to be able to start several independent threads in my
> Rails app. These threads will run as long as the Rails app is running.

A lot of folks have worked on this sort of thing before, and the
general consensus has been that you make your life much easier by
spinning off the threads into a standalone tasks that communicate
with the Rails app using DRb or another RPC mechanism. This will free
you from worrying about the thread/fork/etc. architectures of your
chosen server model (WEBrick, mod_ruby, FCGI runners, etc.).

There's a good introduction to DRb at http://segment7.net/projects/
ruby/drb/introduction.html.

-Ben
This topic is locked and can not be replied to.