Missing Cygwin support

[matzeri]

The explicit usage of sys.platform as

     sys.platform == "linux" 
     sys.platform == "android"
     sys.platform == "win32"

to test the enviroment preclude running trio on cygwin as unsupported platform.

As linux, android, cygwin all have
os.name='posix'

can you please be a bit more inclusive ?
Trio is the only package, that I have found, to have such restricted views and unfortunately is used as needed dependency by other packages

python-tox | ImportError: cannot import name 'current_kqueue' from 'trio._core._run'
python-sniffio | cannot import name 'current_kqueue' from 'trio._core._run'
python-urllib3 | ImportError: cannot import name 'current_kqueue' from 'trio._core._run'
python-decorator | cannot import name 'current_kqueue' from 'trio._core._run'

Thanks in advance
Marco Atzeri (Cygwin Python package maintainer)

[CoolCat467]

If you have a way to fix this easily, feel free to make a pull request. The core problem this stems from is the fact there are different OS-level I/O event systems we have to support to make Trio function properly, and thus different I/O backends are turned on depending on sys.platform checks. Not all posix-complaint systems implement the same I/O primitives.

[A5rocks]

We currently support:

• the windows IO system
• epoll
• kqueue

It looks like kqueue is failing, and looking at the code we only try kqueue if epoll is not available in Python:

elif (
    sys.platform == "linux"
    or sys.platform == "android"
    or (not TYPE_CHECKING and hasattr(select, "epoll"))
):

So concretely you're proposing that we add a check for cygwin for Windows IO? Does cygwin built Python even support the relevant APIs? Notably we depend on cffi for Windows API support, but only conditionally add it as a dependency. So I guess we would also need to update that dependency bound? Is there something we can do to only require it on cygwin to avoid adding an extra dependency everywhere? Here's what we have available to us:

marker_op     = version_cmp | (wsp+ 'in' wsp+) | (wsp+ 'not' wsp+ 'in' wsp+)
python_str_c  = (wsp | letter | digit | '(' | ')' | '.' | '{' | '}' |
                 '-' | '_' | '*' | '#' | ':' | ';' | ',' | '/' | '?' |
                 '[' | ']' | '!' | '~' | '`' | '@' | '$' | '%' | '^' |
                 '&' | '=' | '+' | '|' | '<' | '>' )
dquote        = '"'
squote        = '\\''
python_str    = (squote (python_str_c | dquote)* squote |
                 dquote (python_str_c | squote)* dquote)
env_var       = ('python_version' | 'python_full_version' |
                 'os_name' | 'sys_platform' | 'platform_release' |
                 'platform_system' | 'platform_version' |
                 'platform_machine' | 'platform_python_implementation' |
                 'implementation_name' | 'implementation_version' |
                 'extra' | 'extras' | 'dependency_groups' # ONLY when defined by a containing layer
                 )
marker_var    = wsp* (env_var | python_str)
marker_expr   = marker_var marker_op marker_var
              | wsp* '(' marker wsp* ')'
marker_and    = marker_expr wsp* 'and' marker_expr
              | marker_expr
marker_or     = marker_and wsp* 'or' marker_and
                  | marker_and
marker        = marker_or
quoted_marker = ';' wsp* marker

(I think basically: is there somethign listed in env_var which we can use to differentiate cygwin from everything else? Sorry, I'm unfamiliar with what cygwin provides.)

[matzeri]

Cygwin is a Unix platform. Not a Win32 platform. Usually programs that assume Vanilla Unix behaviour work fine with no major inconvenience Il Mar 15 Set 2026, 05:46 A5rocks ***@***.***> ha scritto:

…

*A5rocks* left a comment (python-trio/trio#3513) <#3513 (comment)> We currently support: - the windows IO system - epoll - kqueue It looks like kqueue is failing, and looking at the code we only try kqueue if epoll is not available in Python: elif ( sys.platform == "linux" or sys.platform == "android" or (not TYPE_CHECKING and hasattr(select, "epoll")) ): So concretely you're proposing that we add a check for cygwin for Windows IO? Does cygwin built Python even support the relevant APIs? Notably we depend on cffi for Windows API support, but only conditionally add it as a dependency. So I guess we would *also* need to update that dependency bound? Is there something we can do to only require it on cygwin to avoid adding an extra dependency everywhere? Here's what we have available to us: marker_op = version_cmp | (wsp+ 'in' wsp+) | (wsp+ 'not' wsp+ 'in' wsp+) python_str_c = (wsp | letter | digit | '(' | ')' | '.' | '{' | '}' | '-' | '_' | '*' | '#' | ':' | ';' | ',' | '/' | '?' | '[' | ']' | '!' | '~' | '`' | '@' | '$' | '%' | '^' | '&' | '=' | '+' | '|' | '<' | '>' ) dquote = '"' squote = '\\'' python_str = (squote (python_str_c | dquote)* squote | dquote (python_str_c | squote)* dquote) env_var = ('python_version' | 'python_full_version' | 'os_name' | 'sys_platform' | 'platform_release' | 'platform_system' | 'platform_version' | 'platform_machine' | 'platform_python_implementation' | 'implementation_name' | 'implementation_version' | 'extra' | 'extras' | 'dependency_groups' # ONLY when defined by a containing layer ) marker_var = wsp* (env_var | python_str) marker_expr = marker_var marker_op marker_var | wsp* '(' marker wsp* ')' marker_and = marker_expr wsp* 'and' marker_expr | marker_expr marker_or = marker_and wsp* 'or' marker_and | marker_and marker = marker_or quoted_marker = ';' wsp* marker (I think basically: is there somethign listed in env_var which we can use to differentiate cygwin from everything else? Sorry, I'm unfamiliar with what cygwin provides.) — Reply to this email directly, view it on GitHub <#3513?email_source=notifications&email_token=AAXXAA7M5QD2GNNNHWW22OL5PC3S5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRXGQ2DENBXHEYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5674424790>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXXAA6562GLGRDIN54F2735PC3S5AVCNFSNUABEKJSXA33TNF2G64TZHM3TSMBYGM3DCNB3JFZXG5LFHM2TINBUHEZDCNZZHGQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAXXAA27OTZ4KCT5ATDU3T35PC3S5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRXGQ2DENBXHEYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/AAXXAA6II2SJFT6GYY75RVL5PC3S5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRXGQ2DENBXHEYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[oremanj]

Usually programs that assume Vanilla Unix behaviour work fine with no major inconvenience

Unfortunately the "vanilla Unix behavior" for multiplexed I/O readiness (select or poll), which Cygwin does appear to support, is decades old. It does not scale well to large numbers of connections and is difficult to use from multiple threads (which is relevant for Trio's "guest mode" feature). Trio supports more modern alternatives such as epoll (Linux), kqueue (BSD/macOS), and IOCP (native Windows), which don't have these issues. Unfortunately, Cygwin doesn't support any of these.

If you want Cygwin support on Trio, you will need to create a new IOManager type for it. It can use select or poll. These will have worse performance than the other IOManager types that Trio supports, and they also will not work with guest mode due to thread-safety issues.

[njsmith]

It is possible to call win32 apis inside cygwin programs so it might also be possible to get the iocp backend working, but I suspect you'd have to work through issues at the cygwin/win32 boundary (eg I'm not sure whether `socket.socket` returns a real win32 socket on cygwin, or some indirection layer on top of one).

…

On Tue, Sep 15, 2026, 08:55 Joshua Oreman ***@***.***> wrote: *oremanj* left a comment (python-trio/trio#3513) <#3513 (comment)> Usually programs that assume Vanilla Unix behaviour work fine with no major inconvenience Unfortunately the "vanilla Unix behavior" for multiplexed I/O readiness (select or poll), which Cygwin does appear to support, is decades old. It does not scale well to large numbers of connections and is difficult to use from multiple threads (which is relevant for Trio's "guest mode" feature). Trio supports more modern alternatives such as epoll (Linux), kqueue (BSD/macOS), and IOCP (native WIndows), which don't have these issues. Unfortunately, Cygwin doesn't support any of these. If you want Cygwin support on Trio, you will need to create a new IOManager type for it. It can use select or poll. These will have worse performance than the other IOManager types that Trio supports, and they also will not work with guest mode due to thread-safety issues. — Reply to this email directly, view it on GitHub <#3513?email_source=notifications&email_token=AAEU42DGG65AAH36UNHPVWT5PFRABA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRYGM2DMOBSGY42M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5683468269>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEU42ADH3GWBNX3I4ETO3T5PFRABAVCNFSNUABEKJSXA33TNF2G64TZHM3TSMBYGM3DCNB3JFZXG5LFHM2TINBUHEZDCNZZHGQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAEU42ADXT4I2XH7HPSMFC35PFRABA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRYGM2DMOBSGY42M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AAEU42HX77D243ADXSWNKUT5PFRABA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRYGM2DMOBSGY42M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>