Hello, I''m new to the list so I''d like to first greet everybody and thank Ezra for the nice solution to an old problem. I also have a warm-up newbie question. What happens if I send a request to a worker that in that moment is working on some other talk? Does it wait for the worker to finish his current method and than evaluate my request, does it interrupt the worker to handle the request or does it simply spawn another thread for it? Thanks. Cosmin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080210/af843b9a/attachment-0001.html
Hi On Sun, 2008-02-10 at 14:54 +0200, Cosmin Radoi wrote:> > Hello, > > I''m new to the list so I''d like to first greet everybody and thank > Ezra for the nice solution to an old problem. > > I also have a warm-up newbie question. What happens if I send a > request to a worker that in that moment is working on some other talk? > Does it wait for the worker to finish his current method and than > evaluate my request, does it interrupt the worker to handle the > request or does it simply spawn another thread for it? > Thanks. >If you invoke ask_work on a worker thats already processing a task( in a totally blocking manner ), then your request will be queued in master process send_data buffer, until your worker is free and ready to remove the data ready at the socket and start executing next task. Since bdrb makes use of non blocking IO and select call to check for availability of data at the socket, assuming your worker is doing some processing because of which reactor loop is not able to run through next iteration ( in each iteration it checks if there is data to be read from the socket ), your request will be queued up in socket buffer. For couple of requests this fine, but if you are making too many requests and your requests are getting queued in socket buffer, its not a good. However, if you are processing too many tasks and want to spawn a thread for them, you can rather use inbuilt, "thread_pool" to defer execution of tasks to a pool of threads. It works nicely and will probably work better than roll your own thread solution. For more information refer the README file or documentation here at: http://backgroundrb.rubyforge.org Finally in no case, a running tasks gets interrupted.
Am I understanding correctly that a task that is doing work would get interrupted and it''s current job is effectively canceled? Alex On Feb 10, 2008, at 6:29 AM, hemant kumar wrote:> > Hi > On Sun, 2008-02-10 at 14:54 +0200, Cosmin Radoi wrote: >> >> Hello, >> >> I''m new to the list so I''d like to first greet everybody and thank >> Ezra for the nice solution to an old problem. >> >> I also have a warm-up newbie question. What happens if I send a >> request to a worker that in that moment is working on some other >> talk? >> Does it wait for the worker to finish his current method and than >> evaluate my request, does it interrupt the worker to handle the >> request or does it simply spawn another thread for it? >> Thanks. >> > > If you invoke ask_work on a worker thats already processing a > task( in a > totally blocking manner ), then your request will be queued in master > process send_data buffer, until your worker is free and ready to > remove > the data ready at the socket and start executing next task. > > Since bdrb makes use of non blocking IO and select call to check for > availability of data at the socket, assuming your worker is doing some > processing because of which reactor loop is not able to run through > next > iteration ( in each iteration it checks if there is data to be read > from > the socket ), your request will be queued up in socket buffer. For > couple of requests this fine, but if you are making too many requests > and your requests are getting queued in socket buffer, its not a good. > > However, if you are processing too many tasks and want to spawn a > thread > for them, you can rather use inbuilt, "thread_pool" to defer execution > of tasks to a pool of threads. It works nicely and will probably work > better than roll your own thread solution. > > For more information refer the README file or documentation here at: > > http://backgroundrb.rubyforge.org > > Finally in no case, a running tasks gets interrupted. > > > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
On Feb 10, 2008 3:59 PM, Alex Soto <apsoto at gmail.com> wrote:> Am I understanding correctly that a task that is doing work would get > interrupted and it''s current job is effectively canceled?No, as Hemant said at the end of his email, no running job will ever be interrupted. That would pretty much defeat the purpose of BackgrounDRb. Ryan