# Best way to start new ruby script? **URL:** \ **Category:** Ruby\ **Created:** [March 8, 2006, 10:18pm UTC](https://www.ruby-forum.com/t/best-way-to-start-new-ruby-script/54576 "2006-03-08T22:18:38Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![marcan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/6bbea6/32.png) [@marcan](https://www.ruby-forum.com/u/marcan)\ **Post date:** [March 8, 2006, 10:18pm UTC](https://www.ruby-forum.com/t/best-way-to-start-new-ruby-script/54576/1 "2006-03-08T22:18:38Z")
I have a long running process that I want to start from a Rails request. But, because it takes so long to execute, I want to start it in a separate process and then return. What is the best way to do that? Thanks /Marcus ---
**Author:** ![marcan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/6bbea6/32.png) [@marcan](https://www.ruby-forum.com/u/marcan)\ **Post date:** [March 8, 2006, 11:44pm UTC](https://www.ruby-forum.com/t/best-way-to-start-new-ruby-script/54576/2 "2006-03-08T23:44:34Z")
2006/3/8, Marcus A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > I have a long running process that I want to start from a Rails request. > But, because it takes so long to execute, I want to start it in a > separate process and then return. What is the best way to do that? You have several options - at leas these: - do it in a thread - create a new process using fork’s block form, which executes the block in the child - create a completely new process via a standard fork call Which one is best depends on the problem you are trying to solve, # of CPU’s available, personal taste etc. Kind regards robert ---
**Author:** ![marcan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/6bbea6/32.png) [@marcan](https://www.ruby-forum.com/u/marcan)\ **Post date:** [March 9, 2006, 12:05am UTC](https://www.ruby-forum.com/t/best-way-to-start-new-ruby-script/54576/3 "2006-03-09T00:05:57Z")
Robert K. wrote: > block in the child > > - create a completely new process via a standard fork call > > Which one is best depends on the problem you are trying to solve, # of > CPU’s available, personal taste etc. Portably, the following works, as long as you don’t mind not having access to its stdin/out: t = Thread.new { system “something” } You can use t.value to wait for the process to finish and determine the result code of the system call (true or false). If you want to read/write to the process look into the various pipe openers: Kernel#open("|something"), Open3, etc. ---
**Author:** ![marcan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/6bbea6/32.png) [@marcan](https://www.ruby-forum.com/u/marcan)\ **Post date:** [March 9, 2006, 2:10am UTC](https://www.ruby-forum.com/t/best-way-to-start-new-ruby-script/54576/4 "2006-03-09T02:10:14Z")
Keep in mind that rails and fork don’t get along very well. If you just plain fork like you wold in a normal ruby scrip[t you will get the Mysql has gone away error and your db connection will be borken. Here is a little hack that will let you get away with forking without losing your db connection in rails: fork do LongProcess.do\_something(that\_takes\_a\_long\_time) Kernel.exec “echo -n” end ``` That last Kernel.exec "echo -n" is the hack that will keep your db ``` connection from “going away” Cheers- -Ezra ---
**Author:** ![marcan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/6bbea6/32.png) [@marcan](https://www.ruby-forum.com/u/marcan)\ **Post date:** [March 9, 2006, 4:17am UTC](https://www.ruby-forum.com/t/best-way-to-start-new-ruby-script/54576/5 "2006-03-09T04:17:06Z")
On Thu, 9 Mar 2006, Ezra Z. wrote: > Keep in mind that rails and fork don’t get along very well. If you > just plain fork like you wold in a normal ruby scrip[t you will get > the Mysql has gone away error and your db connection will be borken. > Here is a little hack that will let you get away with forking without > losing your db connection in rails: > > fork do # all open file handles duped > LongProcess.do\_something(that\_takes\_a\_long\_time) > Kernel.exec “echo -n” # all duped file handled flushed and closed! > end > > That last Kernel.exec “echo -n” is the hack that will keep your db > connection from “going away” > > Cheers- > -Ezra also, forking while in a db transaction is **bad** idea. not to mention fastcgi… best to start an external job runner daemon and use it via drb. one is included in the rq source but it’s a bit bundled… i coded it for exactly the reasons the op has expressed. kind regards. -a ---
**Author:** ![marcan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/6bbea6/32.png) [@marcan](https://www.ruby-forum.com/u/marcan)\ **Post date:** [March 9, 2006, 8:45am UTC](https://www.ruby-forum.com/t/best-way-to-start-new-ruby-script/54576/6 "2006-03-09T08:45:56Z")
removed\_email\_address@domain.invalid skrev: > best to start an external job runner daemon and use it via drb. one is > included in the rq source but it’s a bit bundled… i coded it for exactly > the reasons the op has expressed. I ended up doing a simple drb service external to the Rails application. I didn’t want to do it at first since I’ve been doing similar things with Java RMI… It starts a new thread (apart from the threads drb starts itself) on every request in order to return directly. Works good. It was extremely simple code. Now I only have to make it a deamon/service. /Marcus ---
**Author:** ![marcan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/6bbea6/32.png) [@marcan](https://www.ruby-forum.com/u/marcan)\ **Post date:** [March 9, 2006, 12:21am UTC](https://www.ruby-forum.com/t/best-way-to-start-new-ruby-script/54576/7 "2006-03-09T00:21:04Z")
Do it in a thread seems like the simplest solution but I don’t know if it works in this setup with Rails and SCGI (Rails may be performing clean up on resources that the thread uses when the request returns while the thread is still running) I just want to be able to invoke the external script in an async manner (passing along a parameter as well somehow) and also so that it doesn’t interfere with Rails way of doing threads (or not doing threads…). Thanks for the answer. /Marcus Robert K. skrev: