Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is missing for windows support? #210

Closed
jkbbwr opened this issue May 2, 2017 · 4 comments
Closed

What is missing for windows support? #210

jkbbwr opened this issue May 2, 2017 · 4 comments

Comments

@jkbbwr
Copy link

jkbbwr commented May 2, 2017

Can we get a checklist of what exactly is missing, or needs to be done or has been tried to get windows support? Maybe make this a meta issue.

@njsmith
Copy link
Contributor

njsmith commented May 2, 2017

One that caught me by surprise is that it turns out that everywhere aside from windows, SO_REUSEADDR is a thing you want to enable on every socket all the time, but on windows it does some horribly broken thing instead (it gives permission to random other processes to hijack your socket). In trio I actually refuse to re-export it from the trio.socket module because wtf this is not useful to anyone, and turn on SO_EXCLUSIVEADDR instead (this is more controversial; unfortunately neither option windows gives you here is going to make everyone happy, so I figured I'd err on the side of more security. There's some more discussion in python-trio/trio#72).

Beyond #29 [edit: never mind, it looks like this got fixed in #159 and I missed it], subprocess support and CI testing are probably the major issues. In general trio might be useful to consult, b/c it has full first-class windows support and extremely high test coverage so I have pretty high confidence that I've caught the worst issues. (No subprocess support yet though, hopefully soon.)

@njsmith
Copy link
Contributor

njsmith commented May 2, 2017

Oh, and if you want to get serious about Windows and add IOCP support (#68), then this has a whole bundle of surprising traps; my current understanding is summarized here: python-trio/trio#52

@goldcode
Copy link

goldcode commented May 2, 2017

From #68 (comment)
Does this mean at any time on Windows only 64 tasks can run in parallel?

@njsmith
Copy link
Contributor

njsmith commented May 2, 2017

That comment is incorrect; Python's select can handle 512 sockets on Windows (and that's per fdset, so a maximum of 1024 tasks in total could block waiting for sockets simultaneously if half were waiting to read and half were waiting to write). It'd also be straightforward in principle to raise that limit by implementing a custom wrapper for select, but that would be a significant departure from curio's approach so far of relying on the standard library to abstract over platform differences.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants