[Backgroundrb-devel] [ANN] BackgrounDRb New release.

David Lemstra david at lemstra.ca
Sun Jul 2 00:22:25 EDT 2006

Nifty stuff Ezra!
Haven't had time to test yet, but just want to point out something that
I'm worried could cause people some grief, unless I'm missing something.

> One of the new things is much better threading job control. This is
> mostly invisible to you as a user of the plugin but it makes the
> whole system a lot more sturdy. It gives your worker objects the
> chance to clean up after themselves when they get deleted instead of
> just getting the kill brick dropped on them ;)

The assumption is that your worker class has some kind of a loop and
calls 'terminate' somewhere in the loop where it is safe to kill (or
uses 'check_terminate' to see if we should cleanup and then call
'terminate'). 'terminate' then raises a signal saying it is OK to be

The problem:
by default, if you don't call 'terminate' anywhere in the worker class,
the OK-to-Kill signal is never raised, so 'delete_worker' never follows
through and kills the worker, but instead sits there waiting for the
OK-to-kill signal.

Maybe the worker class should have a variable (off by default) that
enables this behaviour? When I sent out the code, I assumed it'd be a
reference and people would know that they should use terminate if they
went that route. Now I'm afraid people will upgrade but not realize
their processes are no longer being killed.

I think a simple condition shoved in like:
if (@jobs[key].jb_ctrl) then do_the_signal_stuff end
Then @jb_ctrl must be enabled in worker class.

def delete_worker(key)
  @mutex.synchronize {
    if @jobs[key]
      if @jobs[key].respond_to? :thread
        if @jobs[key].thread.alive?
	  if @jobs[key].jb_ctrl
            @jobs[key].thread[:kill] = true;
    @timestamps.delete(key) if @timestamps.has_key?(key)

> I would also like to start collecting worker classes or at
> least hear what folks are using this plugin for.
I'm using it to do a hole whack of calculations w/ the database in the
background. BackgrounDRb keeps my www server responsive and lets me use
periodically_call_remote() to update a progress bar. W/ the job control,
www clients can even cancel the calculations.

David Lemstra

More information about the Backgroundrb-devel mailing list