windows support?

[sunwangme]

wonderful project！when to suppert windows?

[1st1]

When we find a volunteer to implement it ;)

[brickgao]

@1st1 Hi, I'm interested in implementing this proposal, is anyone already working on it ;)?

[1st1]

@brickgao As far as I know no one is.

[brickgao]

@1st1 I have a little trouble porting posix.signal to Windows in https://github.com/MagicStack/uvloop/blob/master/uvloop/os_signal.pyx#L1 . I could not find a good way to implement it because of the difference in signal between Windows and *nix. Could you please give me some advice?

[1st1]

I don't think Windows supports signals, so you should probably add checks like if not __WINDOWS__ around code that touches loop.py_signals and loop.uv_signals.

[1st1]

@brickgao Do you think we should find more people to look into this problem?

[brickgao]

@1st1 Sure, I find that there isn't a quick way to port uvloop with the native Windows API. I would try to port uvloop with Cygwin these days first, cuz I find Cygwin provide most of the *NIX API on Windows.

[brickgao]

@1st1 I find that Cygwin haven't provided Python3.5 officially :(, so we should work on it with the native Windows API again. Maybe we should find more people to look into this problem.

There are two major parts we need to port, socket and signal.

For socket, most of socket functions could be easy to ported by changing the header file, but Windows don't provide socketpair. Referring to https://github.com/ncm/selectable-socketpair and https://github.com/python/cpython/blob/c6ae2fcc724cbebb14e7c434b89eabdd64802cb3/Lib/asyncio/windows_utils.py#L37, it's possible to implement a socketpair that support AF_INET and AF_INET6, but it doesn't support AF_UNIX.
For signal, Windows provides a function signal(https://msdn.microsoft.com/en-us/library/xdkz3x12.aspx) to change the handlers of specific signal, but it doesn't provide the function to get the current handler of specific signal and it also doesn't provide sigfillset.

[schlamar]

Libuv already provides a platform agnostic interface to signals and sockets (e.g. http://docs.libuv.org/en/v1.x/signal.html). You shouldn't have to deal with the Windows API at all.

[1st1]

@schlamar You should have looked at uvloop source code first, before assuming that we don't know some basic libuv APIs.

@brickgao Sorry for the delayed reply. For signals specifically I use sigaction to make sure that:

1. uvloop restores CPython's signal handlers
2. Ctrl+C is handled correctly, i.e. PyErr_SetInterrupt is called when uvloop runs Python callbacks.

For the Windows port we don't need (1). We might need to play with Windows APIs to workaround (2), I suggest you to look at how CPython handles Ctrl+C on Windows.

As for socketpair–the whole subprocess handling code is complicated. I had to copy the logic from subprocess.py (and its C-level helper) to make uvloop's subprocess behave exactly like CPython's. Good news is that we can learn how subprocess.py uses Windows APIs, and copy that approach to uvloop.

[iceboy233]

Had a quick hack to make it buildable in windows (win7, python 3.5.2 x64): https://github.com/iceb0y/uvloop/commit/fa2b7db1d7940149bb8d16e856e7d1a642f3e6b8

build snippet:
in /vendor/libuv, use python2

vcbuild.bat x64 release

in /, use python3, do the same as makefile

cython -3 -a -p uvloop/loop.pyx
python setup.py build_ext --inplace

Had a test with aiohttp server - the current stucking problem is that uvloop uses os_dup in multiple places to duplicate UVSocketHandle._fileno, where os_dup = os.dup and it duplicates posix file handles. In windows, posix file handle is implemented as an additional layer on NT handles where the handle numbers are not equal. I workaround this problem and aiohttp server works.

Notice that os_dup is also used to duplicate posix handle in uvloop/loop.pyx and uvloop/handles/process.pyx. So we need to differentiate between this two kinds of dups. Also note that duplicating socket handles in windows is fragile (see http://bugs.python.org/issue14522). If we can share socket by sharing handle objects instead of duplicating OS handles, we can resolve this problem and avoid the dup system call.

[iceboy233]

dup is introduced in 6e9c43b

maybe we need to find another way to solve the problem described by the commit?

[1st1]

Your PR looks very good, thanks a lot for working on this. I believe we don't need to do anything special for signals or forks. As for dup, I'll fix a bug in asyncio and change how uvloop implements get_extra_info in a couple of weeks.