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

Michael Siebert siebertm85 at googlemail.com
Mon Apr 14 03:03:53 EDT 2008


this is great news (although i use windows only for playing games).  
when it comes to fork, i can remember from my before-mac-time that  
there is a rubyforge project called win32-utils (http://rubyforge.org/projects/win32utils/ 
) which implements things like fork and possibly killing of a process  

the thing with the tests ist: backgroundrb doesnt seem to have tests.  
include them :)

Am 14.04.2008 um 02:44 schrieb Brian Morearty:
> 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
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel

Siebert WD
Michael Siebert
Trappenweg 6, 15749 Mittenwalde, Deutschland

More information about the Backgroundrb-devel mailing list