Brain,
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
tree.
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
> [email protected]
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
---
Siebert WD
Michael Siebert
Trappenweg 6, 15749 Mittenwalde, Deutschland
_______________________________________________
Backgroundrb-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/backgroundrb-devel
