[Backgroundrb-devel] backgroundrb preview
gethemant at gmail.com
Sun Nov 5 13:59:06 EST 2006
On 11/5/06, skaar <skaar at waste.org> wrote:
> > 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
> 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
> > 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.
The cloud has cleared...I can see clear blue sky. Days of slavery has
PS: Can we have a mirror of backgroundrb SVN at rubyforge also?
devjavu SVN doesn't play nice with people behind proxies.
There was only one Road; that it was like a great river: its springs
were at every doorstep, and every path was its tributary.
More information about the Backgroundrb-devel