> > > This help significantly in improving stability of BackgrounDRb and code > > written on top of packet. So what you guys think? Shall we go for this > > change? > > It sounds good to me. Anything that helps stability and improves > memory usage will always get my vote. I agree. Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080413/1d589f...
On Sun, 2008-04-13 at 16:41 -0700, Paul Kmiec wrote: > > This help significantly in improving stability of > BackgrounDRb and code > > written on top of packet. So what you guys think? Shall we > go for this > > change? > > It sounds good to me. Anything that helps stability and > improves > memory usage will always get my vote. > > I agree. > > Paul Okay folks, I have updated git repo of just packet with latest changes wherein I have removed fork in favour of fork and exec: http://github.com/gnufied/packet/tree/master The only catch is, now we need some kinda runner to run our workers since exec takes argument in form of string only. For example: exec "packet_worker_runner ##{t_worker_name}:{worker_read_end.fileno}:#{worker_write_end.fileno}:#{option_dump_length}" One option we have is to have "packet_worker_runner" as installed executable when user installs packet gem. Any other ideas?
> One option we have is to have "packet_worker_runner" as installed executable when user installs packet gem. The more I think about the idea of a packet runner, the more I like it. One reason I like it: it solves a problem with the Windows port I wrote. The Windows implementation needs to know what process to launch to create a new worker. It currently relaunches PACKET_APP, but I was concerned that might be a misuse of PACKET_APP and it forces the author of a PACKET_APP to implement code like what I wrote in script/backgroundrb to handle a "worker parameter. If there's a separate app whose only purpose in life is to be the runner, no one else has to write code to handle those parameters. - Brian On Sun, Apr 13, 2008 at 6:53 PM, hemant kumar <gethemant at gmail.com> wrote: > > On Sun, 2008-04-13 at 16:41 -0700, Paul Kmiec wrote: > > > This help significantly in improving stability of > > BackgrounDRb and code > > > written on top of packet. So what you guys think? Shall we > > go for this > > > change? > > > > It sounds good to me. Anything that helps stability and > > improves > > memory usage will always get my vote. > > > > I agree. > > > > Paul > > Okay folks, > > I have updated git repo of just packet with latest changes wherein > I have removed fork in favour of fork and exec: > > http://github.com/gnufied/packet/tree/master > > The only catch is, now we need some kinda runner to run our workers > since exec takes argument in form of string only. For example: > > exec "packet_worker_runner > ##{t_worker_name}:{worker_read_end.fileno}:#{worker_write_end.fileno}:#{option_dump_length}" > > One option we have is to have "packet_worker_runner" as installed > executable when user installs packet gem. > > Any other ideas? > > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > -- Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080415/873e2d...
On Tue, Apr 15, 2008 at 10:59 PM, Brian Morearty <brian at morearty.org> wrote: > > > One option we have is to have "packet_worker_runner" as installed > executable when user installs packet gem. > > The more I think about the idea of a packet runner, the more I like it. > > One reason I like it: it solves a problem with the Windows port I wrote. The > Windows implementation needs to know what process to launch to create a new > worker. It currently relaunches PACKET_APP, but I was concerned that might > be a misuse of PACKET_APP and it forces the author of a PACKET_APP to > implement code like what I wrote in script/backgroundrb to handle a "worker > parameter. If there's a separate app whose only purpose in life is to be the > runner, no one else has to write code to handle those parameters. > Brian, Just a quick update. I have updated both BackgrounDRb and packet with new changes of fork, exec and runner binaries.I will start merging your changes and making it run on Windows sometime tomorrow. Also, this is our opportunity to have 100% test case coverage of BackgrounDRb. If you can be online on IRC tomorrow, it will be awesome. Time is around 19th April, 18.23 UTC.