[Backgroundrb-devel] Good news: BackgrounDRb now works on Windows

Brian Morearty brian at morearty.org
Sun Apr 13 22:03:55 EDT 2008

I have a couple of patch files I can send the the appropriate place. One for
packet and one for backgroundrb. Am I supposed to send them to this list for
review, email them to hemant, request write access to a SubVersion or Git
repository, or something else?

I need a little handholding with this part so please be patient. :-) I
haven't participated in open source very much so I'm not sure what the
conventions are.

- Brian

On Sun, Apr 13, 2008 at 5:44 PM, Brian Morearty <brian at morearty.org> wrote:

> Hello all,
> I have some good news to announce. I have made some changes to a local
> copy of BackgrounDRb 1.0.3 (actually most of the changes were in Packet
> 0.1.5) and I've got it working on Windows. From what I've read, this is the
> first time it's worked on Windows in a year and a half, since 0.2 was
> released.
>  In my research I can see that a number of people have asked for Windows
> support so I'm excited that I can help out.
> I'm new to this mailing list and new to BackgrounDRb so I would appreciate
> advice and help from you all on things like:
> - how to test my changes. When I run rake it just exits without running
> any tests. I'm not sure why. I also don't know how to test Packet.
> - how to send a patch. I mostly do Windows development where textual
> patches are not commonplace. But I did submit a patch to Rails that was
> accepted, so at least I've done it once with success. :-)
> - a code review to make sure I'm doing things in an approved way
> - someone with *nix to make sure I didn't break anything by accident. I
> tried hard to not but you can't be sure without testing.
> Since I haven't figured out how to run automated tests I have created some
> ad hoc tests of my own. These cases work:
>  - ad hoc scheduling by calling a method on the worker
> - passing parameters to the worker
> - cron scheduling
> - register_status and ask_status
> - making a synchronous call and getting a result back kind of works,
> except I get the whole hash back with the result in the :data key instead of
> just getting the result alone. In other words I get a hash like this:
>    {:type=>:response, :client_signature=>25, :result=>true, :data=>1}
>   which is odd because it's calling the same "extract" function that
> ask_status uses, so I'm not sure why this is any different.
> There are some things I haven't tried yet but it's great that this many
> cases work.
> I definitely have to try to figure out why the return value of a
> synchronous call is the whole hash, and I might need help on that because
> I'm mystified.
> The primary obstacles to making BackgrounDRb work on Windows were:
> 1. UNIXSocket - it wasn't too hard to add code that uses TCPSocket unless
> defined? UNIXSocket. And there were four lines of code that checked if a
> socket was a UNIXSocket to decide whether it's an "internal" read or write,
> but those lines were crashing because UNIXSocket isn't even defined on
> Windows, much less used. My fix for that was to create a marker Module
> called "Packet::InternalSocket." Each time I created an internal socket
> (where the code used to create a UNIXSocket) I now call socket.extend
> Packet::InternalSocket so that later on the code can distinguish the
> internal ones from the others.
> 2. fork - well that's a harder matter. Windows doesn't support fork() and
> probably never will. I saw a recent post by Hemant Kumar mentioning a fix
> that uses fork and exec rather than just fork, but it still requires fork.
> Simulating fork in a generic way is nearly impossible but replacing it in a
> single application is conceivable, depending on what the app does. And in
> this case I was able to do this:
>  a) Leave the existing fork call there
>  b) Fall back on IO.popen for operating systems where fork is not
> supported
>  What I did is for each worker I launch (instead of fork) a new child
> process, pass the read/write port numbers to the child on the command line,
> and wait for it to connect to them.
> Because Rails takes a long time to start up on Windows (11 seconds, ugh)
> you can wait a pretty long time before all your workers are ready (11sec *
> (number of workers+2)). But still, it's better than not being able to use it
> at all. It's perfectly acceptable for a development machine, which is how I
> use Rails on Windows. (My project is going to deploy on something that ends
> in nix.)
> On the other hand if you're going to be dynamically creating background
> workers (e.g. reload_on_schedule true or set_no_auto_load true) you'll wait
> a while for the worker to start up on Windows.
> Will this slow startup time ever block a Rails server request? Not that
> I've seen. From what I've seen BackgrounDRb never starts a new worker
> process because of an API call. The only case I've seen where it starts a
> new worker process on the fly is for a scheduled background task using the
> cron feature. But I may have missed something.
> Another thing that I didn't implement (at least not for now): support for
> the "start" parameter to run the background processes as hidden processes.
> For now on Windows you just have to run script/backgroundrb without the
> start parameter and just leave it running in a console. (But I did make the
> error message nicer.) The reason I didn't: Ruby does not seem to have
> implemented a way to kill a process tree in Windows. Windows doesn't have a
> single API to kill a process tree. You can add all the processes to a Job
> and kill that, or you can enumerate the descendants of a process and kill
> them all one by one. I just didn't want to bother adding the code to Ruby do
> that, at least not now, because it works well enough in a console.
> And the nice thing is Ctrl+C from the console does indeed kill the whole
> process tree.
> That's it for now. Please let me know how to proceed so us Windows users
> can benefit from the wonderfulness of BackgrounDRb.
> --
> Brian Morearty

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080413/5e1f4521/attachment-0001.html 

More information about the Backgroundrb-devel mailing list