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

Brian Morearty brian at morearty.org
Sun Apr 13 22:07:26 EDT 2008

P.S. Hemant I did see your note "(I am looking at you Brian too)" in the
other thread where you mentioned anyone interested in hacking at Packet can
start with that Git repository. And my name's Brian so maybe you meant me.

I'm just not sure what I'm supposed to do there. Just check it in? (Is that
repository a playground that's open to anyone?)

Thanks again.

- Brian

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

> 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
> >
> >
> --
> Brian

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

More information about the Backgroundrb-devel mailing list