Thoughts on better Windows support

[thbar]

Here's a quick status after my #61 fix is applied:

• JRuby + Windows seems to work on my production - because Kernel.fork is not implemented (so ps is not called anymore after the patch)
• MRI + Windows has Kernel.fork enabled, but ps and grep are missing so this probably gives unpredictable behaviour in kill_child (not tested by me)
• predictable behaviour should be achievable with MRI + Windows if 1) cant_fork is set to false + 2) use_wmic is set to true
• fork support without ps requires more work on MRI Windows, after my patch

And here are some ideas to improve stuff:

• when resque:work starts, ensure that 'ps' and 'grep' are available, raise an error maybe if they are not ?
• for each of JRuby Windows, MRI Windows, IronRuby, give some tips and explanation (wmic/ps etc)
• document all this in a Windows section in the README (I can work on that)

[defunkt]

I like the idea of adding a Windows section to the README. Are you using a non-forking Resque in production right now on Windows?

[thbar]

I can work on that later on (once we settle these wmic things on the other issue :-)

I use a non-forking Resque worker in production with JRuby on Windows. Actually the worker will spawn a new process using IO.popen, because the actual work requires Java API access to native system and things that may leak :D

Yes: non-forking Resque with JRuby on Windows.

[defunkt]

Okay, I've been thinking about this and the best approach in my mind is to create a fork of Resque (maybe resque-windows) that overrides the correct methods or adds the needed functionality.

Having everything live in one gem is nice, but it really complicates the integrity of the project - it's hard to fix bugs on a system you have no means to test.

While traditionally this kind of fork would have been difficult, with git I think it could work out really well. The Resque plugin ecosystem seems to be doing well, in any case. What do you think?

[thbar]

I've been thinking a bit about that - my only fear is that the windows version could become out-of-date or unreliable, because I won't be able to keep up with testing (here I'm doing a project for a customer but I don't think I'll update this version often once it's deployed, actually).

But it may work well if there are only limited difference points, that said...

One idea: what about having a small "portable" gem that would do the low-level ps/find stuff and that resque would rely on ? The gem would only care about retrieving processes (ps/find), but would automatically do what the platform require. Resque would have only to interact with this gem for ps stuff.

What do you think (on both my 'fear' to see resque outdated on windows and the last gem idea) ? Not sure exactly what to think yet :)

[defunkt]

I don't think we can offer Windows support if no one is willing to maintain it. Adding a "portable" gem is great, but that doesn't guarantee future changes in Resque won't introduce changes which break on Windows. It'd be like a false promise.

If you publish a version of Resque that works on Windows, I think it's okay to say "We are using this in production but can't promise it will be maintained in the future." Then someone who wants Resque to work on Windows can find it, use it, and potentially improve it.

[thbar]

Sure - I'll do it this way then, it makes sense.

[defunkt]

Closing this as a maintained fork is the way to go for Windows support.