[Backgroundrb-devel] backgroundrb preview

skaar skaar at waste.org
Sat Nov 4 22:19:05 EST 2006


>     worker.read_from_socket  ##### interesting line #666
>
> now..on #666, how do i make sure..that controller just triggers the
> method in worker and control comes back to the controller immediately.
> Sounds like a typical use case of threads.

it's not yet documented, but used internally for do_work, but you could
call:

   worker.work_thread(:method => :read_from_socket)

which will run the method in a separate thread in the worker process. (I
would have to werify how work_thread behaves without arguments, but we
can deal with that - please submit a ticket if you find that it doesn't
work).

> simple_label3:
>   |  :class: :example_worker
>   |  :job_key: :job_key3
>   |  :worker_method: :do_work
>   |  :trigger_args:
>   |    :repeat_interval: 10.minute
> 
> Now..why on earth, I should delete this worker..once it finishes
> processing at the end of each cycle? Surely..i am missing something or
> is that the case...or else I will have a basket full of workers doing
> same job over and over again..until earth tips over.

in the example above you would not have this problem, nor a reason to
delete the worker. You are using :job_key here, which means singleton
worker. It's primarily in cases where you _don't_ specify the job_key
that you have to look out for "spurious" workers.

/skaar


-- 
----------------------------------------------------------------------
|\|\             where in the       |          s_u_b_s_t_r_u_c_t_i_o_n 
| | >===========  W.A.S.T.E.        |                  genarratologies 
|/|/    (_)     is the wisdom       |                  skaar at waste.org
----------------------------------------------------------------------


More information about the Backgroundrb-devel mailing list