Windows 10, OSError: [WinError 10022] An invalid argument was supplied

[maxskorr]

Hi!
Running the following "getting started" code:

async def countdown(n):
    while n > 0:
        print('T-minus', n)
        await curio.sleep(1)
        n -= 1

if __name__ == '__main__':
    curio.run(countdown(10))

results in the following output:

T-minus 10
Traceback (most recent call last):
  File ".../Projects/curio_test/test.py", line 24, in <module>
    curio.run(countdown(10))
  File "...\VirtualEnvs\curio_test\lib\site-packages\curio\kernel.py", line 613, in run
    result = kernel.run(coro, shutdown=True)
  File "...\VirtualEnvs\curio_test\lib\site-packages\curio\kernel.py", line 491, in run
    events = selector_select(timeout)
  File "...\Python\Python35\lib\selectors.py", line 323, in select
    r, w, _ = self._select(self._readers, self._writers, [], timeout)
  File "...\Python\Python35\lib\selectors.py", line 314, in _select
    r, w, x = select.select(r, w, w, timeout)
OSError: [WinError 10022] An invalid argument was supplied

OS: Windows 10 x64
Python: 3.5.2

[roger-]

I'm getting this too on the same setup. Were you able to get it working?

I've used curio in Windows in the past without problems, so a recent change may have broken it.

[maxskorr]

Were you able to get it working?

No, I wasn't(

[dabeaz]

Just a note that Curio has only been tested on POSIX/Unix and that the fact that it might have worked on Windows is purely accidental (I can imagine many of its core features such as signal handling not working).

That said, I'm not opposed to having it work on Windows. I just don't have the resources to personally focus on that right now. I will consider pull requests that improve Windows support and fix bugs. Thus, I'm going to leave this issue open for now.

[mafemergency]

Windows will return immediately (and an error) when trying to select() on three empty sets, this differs from the POSIX api which will block if given a timeout. A work-around might look like:

import curio
import selectors
import socket

dummy_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

async def countdown(n):
    while n > 0:
        print('T-minus', n)
        await curio.sleep(1)
        n -= 1

if __name__ == '__main__':
    selector = selectors.DefaultSelector()
    selector.register(dummy_socket, selectors.EVENT_READ)
    curio.run(countdown(100000), selector=selector)

[swfiua]

Thanks mafemergency for the select on 3 empty sets on windows issue.

I am also using curio on windows 7, but have ubuntu along side, so can check if problems are down to my code (usually the case) or windows weirdness.

So far it is mostly behaving itself, except for select on three empty sets.

Would be nice if this could be fixed in a way that makes the windows behaviour match linux, but without impacting linux performance.

I was hoping that windows 10 with its "Windows Subsystem for Linux" might have a select that works -- but don't have a windows 10 machine to play with for now.

Thanks for curio, I am finding it very, very helpful in understanding how to use async and await -- plus it is doing 99% of what I want to do async wise.

[njsmith]

Really this is a bug in selectors -- I guess it's possible there might still be time to fix it upstream before 3.6, though that doesn't help in the short term. I wonder how asyncio avoids it -- maybe they unconditionally create the waker socket, so they never ran into it?

If folks want to improve windows support, then some concrete things that might be worth considering:

• Make a PR to work around the issue in curio. There are a few possible strategies that might work -- maybe just unconditionally calling _init_loopback at kernel startup would be enough. Or @mafemergency's clever hack. Or even monkeypatching SelectSelector._select to do the right thing...
• submit a patch to Python upstream to avoid this issue. I guess SelectSelector on windows should check for all-empty before calling select.select and fall back to just doing a time.sleep otherwise. Or maybe select.select should implement the workaround directly.
• Set up Appveyor testing for curio, so that new changes get tested on windows

[swfiua]

I think finding something that works in curio is a good start for now.

Thanks for the pointers, I will try and find some time next week to look at this some more.

Stinging bat density seems to have upped a notch -- but they seem to keep their distance, swarming with the manta rays trying to send helpful hints.

[swfiua]

Just came across pep-0475:

System call wrappers provided in the standard library should be
retried automatically when they fail with EINTR , to relieve application
code from the burden of doing so.

By system calls, we mean the functions exposed by the standard C library
pertaining to I/O or handling of other system resources.

it looks like people are already thinking along the right lines.

It also has a good summary of the different signals that windows listens to:

https://www.python.org/dev/peps/7-0475/#signals-on-windows

[swfiua]

select.select selectors readers writers and empty sets.

So this morning pig was running fine under this version of curio:

a8f42c9

which was just before switch to fully batched scheduling:

a8f42c9

So I added the @mafemercency magic here:

openbermuda/karmapi@4a1f422

and now pig is happy everywhere :)

So avoiding select.select(with three empty sets) seems a good workaround.

I suspect that just fixing the pig (and yosser) to just throw everything an EpicQueue and all these problems will go away...

... to be replaced by increased manta ray and bat densities. but it all might just work...

[swfiua]

Per above, making sure there is something to select side-steps the problem.

Rather than just adding a dummy socket, the initial task could be something useful, like a monitor.

I see from this thread that the monitor is separate for a good reason:

#137

But curio could have an internal monitor too and that could be the first thing that is set up.

[njsmith]

See my comment above about calling "_init_loopback"

…

On Dec 6, 2016 7:42 AM, "John Gill" ***@***.***> wrote: Per above, making sure there is something to select side-steps the problem. Rather than just adding a dummy socket, the initial task could be something useful, like a monitor. I see from this thread that the monitor is separate for a good reason: #137 <#137> But curio could have an internal monitor too and that could be the first thing that is set up. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#75 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlOaHeC9CGlDnd1KSsoWjZrCYpuDWbbks5rFYJKgaJpZM4JpHKG> .

[swfiua]

I've tried calling _init_loopback() in a few places but it doesn't seem to solve the problem.

I tried making the call just before the kernel.run() and also within kernel,run() but it hits:

        events = selector_select(timeout)

(around line 713) with still nothing to select from.

Now I have no real idea what _init_loopback() is trying to do, so I might be doing this in the wrong place altogether.

[njsmith]

Filed this upstream as https://bugs.python.org/issue29256 (though curio still needs a workaround)