[Backgroundrb-devel] Is fork { } safe inside of a worker? How else may this be done...

hemant gethemant at gmail.com
Tue Nov 20 20:59:15 EST 2007

On Nov 21, 2007 5:59 AM, Joe Van Dyk <joevandyk at gmail.com> wrote:
> Possibly a related question, If I'm making activerecord updates inside
> multiple brdb workers at the same time, that should be fine, right?
> Wasn't sure how concurrency worked.

Normally your database handles such things. Its no problem at all.

> On Nov 20, 2007 4:06 PM, Adam Roth <adamjroth at gmail.com> wrote:
> > I have a BackgrounDRb worker running every 2 minutes. Here's the basic idea:
> >
> > - events = Event.find_all_pending( 2.minutes )
> > - while( all events have yet to be processed )
> > ---- if( Time.now <= event.time_to_process )
> > ------- fork { process_event }
> > --- end
> > --- sleep( 0.25 )
> > - end
> > - puts "Done..."
> >
> > Events that need to be processed within the next 2 minutes are loaded and
> > iterated over. If its time to process the event, fork and do so. Sleep for
> > 0.25 seconds between loops until all events have been processed.
> >
> > I have a few questions:
> >
> > - Is this safe? Specifically calling fork within a BackgroundRb worker...
> > Some events may fire at the same exact time and cannot be delayed. This is a
> > very time sensitive application.
> > - Is there a better way to handle this scenario?

Which version, are you using older bdrb version, which is still on
trunk or new version which is available here


Please try above new pre-release version, if it suits you. There are
some API differences, but i guess it will work for you.

Ok, back to original question. Its generally safe to fork within
workers, they are just another ruby programs, so shouldn't be
much of a problem there. But the question is, how much time, does
process_event takes?

If window period, between each fire is greater than, time taken by one
invocation of process_event, then you don't need fork.
With new version, each worker has a event loop of its own and hence
you can priortize, firing of events. In older version, it was the
master, who scheduled timer/events in workers. In new version, each
worker is responsible for its own scheduling.

If time window is long enough, you dont need fork. However, I am
working on couple of optimization with new version, so as we don't
search for timers, all the way down to last hash value.

Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.


More information about the Backgroundrb-devel mailing list