# Fork() for long running calculations?

**URL:** <https://www.ruby-forum.com/t/fork-for-long-running-calculations/115528>\
**Category:** Rails\
**Created:** [September 26, 2007, 12:23am UTC](https://www.ruby-forum.com/t/fork-for-long-running-calculations/115528 "2007-09-26T00:23:55Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [September 26, 2007, 12:23am UTC](https://www.ruby-forum.com/t/fork-for-long-running-calculations/115528/1 "2007-09-26T00:23:55Z")

</div>

Hi,

I’m thinking of using fork() for long running calculations in some  
code of mine, that’s run via the Apache fcgid module. It’s some heavy  
calculation/db work that, however, doesn’t need to send anything back  
to the user. Are there any problems with this approach?

Thanks,  
Dave

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [September 26, 2007, 4:50am UTC](https://www.ruby-forum.com/t/fork-for-long-running-calculations/115528/2 "2007-09-26T04:50:07Z")

</div>

> I’m thinking of using fork() for long running calculations in some  
> code of mine, that’s run via the Apache fcgid module. It’s some heavy  
> calculation/db work that, however, doesn’t need to send anything back  
> to the user. Are there any problems with this approach?

Look into backgroundrb first… might work better for you…

[http://backgroundrb.rubyforge.org/](http://backgroundrb.rubyforge.org/)

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [September 26, 2007, 5:44am UTC](https://www.ruby-forum.com/t/fork-for-long-running-calculations/115528/3 "2007-09-26T05:44:28Z")

</div>

fork() is a lot simpler. The only issue was if your process failed-  
you end up with zombie processes that dont get cleaned up until  
reboot. I use it though - make sure you exit gracefully.

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [September 26, 2007, 10:53am UTC](https://www.ruby-forum.com/t/fork-for-long-running-calculations/115528/4 "2007-09-26T10:53:11Z")

</div>

+1 for BackgrounDRb. It’s made exactly for stubbing out longer running  
processes, and I find it a breeze to set up. Not relying on fork() has  
the added advantage that you could get it to work on JRuby or Windows at  
some point in time. (Note that BackgrounDRb currently doesn’t support  
Windows either.)

–  
Roderick van Domburg  
[http://www.nedforce.com](http://www.nedforce.com)

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [October 3, 2007, 3:30pm UTC](https://www.ruby-forum.com/t/fork-for-long-running-calculations/115528/5 "2007-10-03T15:30:46Z")

</div>

though late to the thread, I would recommend activemessaging - just send  
a  
message to a queue, and it can be picked up and processed by another  
process  
(remote or local). Nice thing is you fire and forget - you don’t have  
to  
worry about who processes the message or where it gets processed.

[http://code.google.com/p/activemessaging/](http://code.google.com/p/activemessaging/)

-A

On 9/26/07, Roderick van Domburg [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> ## [http://www.nedforce.com](http://www.nedforce.com)
> 
> Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/).
> 
> >

–  
Andrew K.