Windows compatibility

[ryansm1]

Summary of changes:

• Move code from __main__.py into main.py to prevent picklability errors on Windows when spawning new processes (diff main.py with __main__.py to see line-by-line edits)
• Use multiprocessing's Process to spawn worker processes instead of os.fork()
• Remove TimeLimit middleware on Windows platforms
• Use logging's QueueHandler instead of pipes for interprocess logging
• Setup SIGHUP (POSIX) and SIGBREAK (Windows) signal handlers only if they are available
• Skip tests that cannot pass on Windows (e.g. tests requiring signals)

Known issues:

• Gevent script is broken on Windows

[Bogdanp]

Thanks for doing this! I didn't get a chance to look at these changes this weekend, but I'll try to do it this upcoming one.

[ryansm1]

Hopefully the additional commits don't interrupt your review; I wanted to clean up a couple of things that I missed after my last round of changes. It looks like some of the RabbitMQ retry-after-delay tests fail intermittently.

These are pretty substantial modifications to the main script so I expect them to need some additional work; let me know how I can help!

[Bogdanp]

Thanks again for doing this! I've reviewed your changes and made some of my own on top in #126 . Please take a look and let me know what you think.

I'm going to sit on that PR for a bit because it breaks gevent support (as mentioned in one of your commits) and disabling thread patching is not acceptable since the reason you're likely to run gevent with dramatiq is because you want to run many worker threads concurrently. This PR seems like it may fix the issue but there's no real indication of when it's going to be ready so we might have to find a different solution in the mean time (maybe multiprocessing.Pipes?).

[ryansm1]

I originally converted the logging worker using multiprocessing.Pipes (see removal in #c890dfc) but dropped it in favor of the queue method because there is a native QueueHandler and the code was considerably uglier.

It's easy enough for me to put this back in if you have a good Gevent-based workflow to test against. Assuming it works without omitting the threading monkeypatching, we can explore some way of cleaning the code up (subclassing a base handler?).

I'll send another PR later this week and we can see how you'd like to proceed.

[Bogdanp]

It's easy enough for me to put this back in if you have a good Gevent-based workflow to test against. Assuming it works without omitting the threading monkeypatching, we can explore some way of cleaning the code up (subclassing a base handler?).

Yes, let's try that. I have a couple large applications I could test it on. Also, one thing that's regressed with this change is print calls (i.e. writing to stdout and stderr) are no longer serialized. In master, I redirect each worker process' stdout and stderr to the logging pipe. Perhaps with pipes we can bring that back.