On Sep 14, 2006, at 11:21 AM, Michael Siebert wrote:
>
>
> 2006/9/14, Ezra Zygmuntowicz <ezmobius at gmail.com>:
> Yeah I do have a beta here. It is working very well. What I did to
> make it easier to refactor was to grab an older version. One that
> didn''t have any of the Timing stuff or the Threading stuff for
> ConditionVariables and all that. Once I got it down to its basic
> format, I was able to write a nice ThreadPool class and then use
> that in the MiddleMan. So it is way cleaner now. the middleman
> holds a thread pool and does all the thread management so the
> workers don''t have to. It made the code smaller and much more
robust.
>
> looks nice and is exactly what i need right now. the mor i think
> about your aproach of cleaning it all up, the more i agree. first
> thing i thought was: "hey then my periodically one-tima-a-day-
> running workers wouldnt do it any more!" but isnt it the rails way
> to let the right tools do the right job?
> when it comes to robustness: i have a backgroundrb processrunning
> since 24th of july!
cool ;) I do think it needed cleaning up, it got a bit of feature
bloat I think.
>
>
> I like how lightweight it is right now so I am debating what
> features I want to put back in. In fact this may become
> BackgrounDRb2. That way I can make it nicer now that I know how
> everyone uses it. But this will maybe change the interface a little
> bit so I will leave the current release available for folks that
> already buitl a ton on top of it.
>
> looks very good and simple but one feature i think _must_ make it
> in bgdrb2: some autostarting mechanism (both for backgroundrb and
> workers). possibly some thing to hook into the rails startup - i
> think init.rb would be the place of choice: check the existance of
> log/bgrdb.pid, and if not, touch bgdrb.pid and start it. that could
> event work when launching multiple rails instances
Yeah this is a tough one. I would be great if there was a way to have
it started when you start rails, but I think it will be easier to
keep it separate from rails startup. But what I will do is include a
set of scripts or rake tasks that first start the drb server and then
start rails. Maybe put this script in /script/ and call it to start
everything at once in the right order. And autostart workers will
still be in there too.
>
> I also am working on a way to have ''slaves'' . This would
mean that
> if you passed an extra flag to the new_worker method, the drb
> server will actually fork a new process for your worker to work in,
> and it will setup a heartbeat between the drb server and the slave
> so that when you kill the drb server, all slaves will die because
> they don''t get the heartbeat.
>
> what is the difference between a slave and a normal worker? i guess
> threading? so that thread-unsafe things can work in their own
> process or am i wrong?
Well yes it has to do with threads and horsepower. Sometimes you need
to do really compute intense tasks in a worker like image
manipulation. So instead of sharing one process with all running
workers, you can make some workers that end up running in their own
process to take advantage of multiple cpu''s and more power from more
ruby processes. I am going to integrate this so you don;t even have
to think about it. You can just pass an extra flag and it will run in
another proc, but you will use it the same way from the MiddleMan.
>
> kind regards
> Micha
>
Cheers-
-Ezra
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20060914/881f64bf/attachment.html