Backgroundrb devel - Apr 2008 - Good news: BackgrounDRb now works on Windows

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/dd7c953d/attachment.html

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/5e1f4521/attachment-0001.html

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



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

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
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
---
Siebert WD
Michael Siebert
Trappenweg 6, 15749 Mittenwalde, Deutschland

Brian,

   If you have want to submit a patch to backgroundrb and want to
contribute, you need to create an account with gitorious to have commit
access. But before that please make sure that you are done with perfect set
of test cases. Kindly refer to the organized test cases for backgroundrb [
http://gitorious.org/projects/backgroundrb/repos/mainline/trees/master/test]
inorder to follow the same coding style. You need get it tested in all
versions of windows too... 98,Xp,Vista for confirmation so that you can
create a perfect benchmark of your code. If you need help in testing or
benchmarking or remodelling your code to suit the exact requirements, then
you have to contact hemant for help or else keep going...

Regards,
Kiran.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080414/ef5a57b1/attachment-0001.html

Yeah, I am not sure either. Truthfully, I have not used git before and
haven''t quite grasped it yet. Seems projects (like backgroundrb, RoR)
are starting to move their code trees to git while maintaining svn
access.

Paul

On Sun, Apr 13, 2008 at 7:07 PM, Brian Morearty <brian at morearty.org>
wrote:
> 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
>
>
>
> --
> Brian
> _______________________________________________
>  Backgroundrb-devel mailing list
>  Backgroundrb-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>

On Mon, Apr 14, 2008 at 3:23 PM, Paul Kmiec <paul.kmiec at appfolio.com>
wrote:
> Yeah, I am not sure either. Truthfully, I have not used git before and
> haven''t quite grasped it yet. Seems projects (like backgroundrb,
RoR)
> are starting to move their code trees to git while maintaining svn
> access.
Git is really worth learning. I''m only just beginning with it myself,
but I plan to move all my projects to it eventually. It has nice SVN
integration so you can actually play with it against an SVN repo. Of
course GitHub.com or gitorious.org have plenty of interesting projects
to play with too.

Search video.google.com for a couple Google Tech Talks about Git, one
from Linus himself (more about why he created it) and one from Randal
Swartz that goes into more detail about how to use it.

The Git manual is quite good and can get you going fairly quick, but
also delves into some detail:

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html

There are also lots of other articles and screencasts on the
blogosphere. This is a great (and free) one about using git on a Rails
project:

http://www.vimeo.com/369095

Regards,
Ryan