Skip to content

Missing Cygwin support #3513

Open
Open
Missing Cygwin support#3513

Description

@matzeri
matzeri
opened on Sep 14, 2026

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)

Activity

  1. CoolCat467 commented on Sep 14, 2026

    @CoolCat467
    CoolCat467
    on Sep 14, 2026
    Member

    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.

  2. A5rocks commented on Sep 15, 2026

    @A5rocks
    A5rocks
    on Sep 15, 2026
    Contributor

    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.)

  3. matzeri commented on Sep 15, 2026

    @matzeri
    matzeri
    on Sep 15, 2026 via email
    Author

  4. oremanj commented on Sep 15, 2026

    @oremanj
    oremanj
    on Sep 15, 2026
    Member

    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.

  5. njsmith commented on Sep 15, 2026

    @njsmith
    njsmith
    on Sep 15, 2026 via email
    Member

  6. matzeri commented on Sep 16, 2026

    @matzeri
    matzeri
    on Sep 16, 2026 via email
    Author

  7. njsmith commented on Sep 16, 2026

    @njsmith
    njsmith
    on Sep 16, 2026 via email
    Member
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions