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

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?

Thanks
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20071120/5199f61d/attachment.html

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.

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?
>
> Thanks
> Adam
>
>
>
>
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>

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