dabeaz / curio

Good Curio!
Other
4.04k stars 243 forks source link

What is missing for windows support? #210

Closed jkbbwr closed 4 years ago

jkbbwr commented 7 years ago

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 commented 7 years ago

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 https://github.com/python-trio/trio/issues/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 commented 7 years ago

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: https://github.com/python-trio/trio/issues/52

goldcode commented 7 years ago

From https://github.com/dabeaz/curio/issues/68#issuecomment-263096194 Does this mean at any time on Windows only 64 tasks can run in parallel?

njsmith commented 7 years ago

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.