[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

http://svn.devjavu.com/backgroundrb/branches/version10/

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.

http://gnufied.org


More information about the Backgroundrb-devel mailing list