Forum: Ruby Best way to start new ruby script?

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.
3a6666f57152610f172a77c8fe6a7420?d=identicon&s=25 Marcus Andersson (Guest)
on 2006-03-08 22:18
(Received via mailing list)
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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-03-08 23:44
(Received via mailing list)
2006/3/8, Marcus Andersson <m-lists@bristav.se>:
> 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
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2006-03-09 00:05
(Received via mailing list)
Robert Klemme 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.
3a6666f57152610f172a77c8fe6a7420?d=identicon&s=25 Marcus Andersson (Guest)
on 2006-03-09 00:21
(Received via mailing list)
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 Klemme skrev:
6076c22b65b36f5d75c30bdcfb2fda85?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2006-03-09 02:10
(Received via mailing list)
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
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-03-09 04:17
(Received via mailing list)
On Thu, 9 Mar 2006, Ezra Zygmuntowicz 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
3a6666f57152610f172a77c8fe6a7420?d=identicon&s=25 Marcus Andersson (Guest)
on 2006-03-09 08:45
(Received via mailing list)
ara.t.howard@noaa.gov 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
This topic is locked and can not be replied to.