[Backgroundrb-devel] Hello to the group

Chad Thatcher chad.thatcher at gmail.com
Fri Jan 23 15:16:40 EST 2009

Thanks Hemant,

Yes I was specifically trying to avoid threads.  However, I am  
guessing I could configure it so that only one thread ran at one time  
right?  That would cut down on the complexity.

Is the enq_xxx stuff only time based?  If so I wonder if it would be  
difficult to add a feature that allows you to add a whole bunch of  
tasks to the queue and then they just run one after the other in the  
order in which they were added.  Maybe I could intercept  
persistent_job#finished! to find the next (grouped) task in the queue  
and update it to start a few seconds in the future so the bgrb picks  
it up and runs it etc.  But that seems evil somehow :).

I realise this might not be the target usage for backgroundrb but I  
look forward to hearing your thoughts because I'm hoping it won't be  
too difficult for me to do.  The ultimate fall-back, of course, is to  
roll my own task queue that uses a table similar table to  
bdrb_job_queues but that seems wasteful when there is so much there  
for it already.

All the best,

On 23 Jan 2009, at 18:57, hemant wrote:

> That data is in write Queue of master worker. It can't be meaningfully
> extracted to provide how many tasks are in the queue. Put it other
> way, its not even in a Queue in traditional sense. Data is just there
> in a buffer so that master will write it to the socket when socket is
> ready for write.
> If you want Queue. You will have either use enq_xxx stuff or provide a
> sugar around asyc_index() method so as actual method is not directly
> called but is added to the thread pool (thread_pool.defer), this way
> you can query how many tasks are there in thread pool queue.
> However word "thread" comes with its own meaning and associated
> crapiness in ruby, so beware.
> On Fri, Jan 23, 2009 at 6:35 PM, Chad Thatcher <chad.thatcher at gmail.com 
> > wrote:
>> Hello everyone.
>> I am making several asynchronous calls to one particular method in  
>> my worker
>> like this:
>> MiddleMan.worker(:reindex_worker).async_reindex(:arg => options)
>> If I call this several times in a row, all subsequent calls are put  
>> in a
>> queue and I would like to be able to keep track of this.  The  
>> behavior is
>> perfect because I only ever want reindex() running once at any one  
>> time but
>> I would like to be able to show my users where in the queue their  
>> request
>> is.  Is there any way to view what async calls are lined up?  The
>> worker_info stuff doesn't seem to give away any details like this.
>> I also thought about using "enq_" to schedule but is there a way to  
>> specify
>> that the trigger is the completion of the previous scheduled  
>> instance and so
>> on?  Or is the scheduling purely time based?
>> Kind regards,
>> Chad.
>> _______________________________________________
>> Backgroundrb-devel mailing list
>> Backgroundrb-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
> -- 
> 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