Python 3.4+: use os.set_inheritable + os.set_blocking in place of unreadable fcntl calls

[pajod]

We should cleanup those rather unreadable low-level fcntl calls. The stdlib provides single-call functions for these now.

(Replacement is not 100% equivalent, as they might call ioctl(.., FIO.., NULL) instead, but I see no reason we should care.)

• Fixes: Missing test cases for workers #2742
• Related: test OSX and other platforms in CI #1170

---

Suggested order:

• Merge CI: revert macos-14 runners, migrate to tox v4-exclusive settings, add Python 3.13 #3211 before this one
• Merge before Use plain socket objects instead of wrapper classes #3127 - alternatively verify .fileno() suffixes that might to be dropped

[benoitc]

Not disagreeing about this change but this must be validated on BSD. I think we need to add FreeBSD to our test platform to ensure it works there. (an dmaybe other OpenBSD).

[pajod]

@benoitc Happy with pulling Neil Pang's vm images?

Those work with very little setup required for FreeBSD, OpenBSD and illumos (no prebuilt gevent though). Though the Github file still needs review by someone more proficient with that:

• I did not know how to express "whatever python3 version you usually do" on those images
• I did not know if/how mixing GitHub CI secrets with running arbitrary untrusted code in another CI workflow can be done safely.
• The actual test I meant to run did not run on those systems yet (thats what the s in tests/test_nginx.py s indicates) - my current nginx test does not produce very nice messages when failing
• afaict, OmniOS does not ship gevent, so setup including compilation is rather slow / does not work because libev believes it is on linux and tries to prepare for the existing inotify.h with two-argument statfs() needs some autoconf override in the CI workflow

[benoitc]

i will look at this branch but I am questionning the goal pursued there. One of the point of keeping low level though is to not depends on how one external dev think things should work. Knowing and controlling low level access allows us to understand and track more accurately some issues. Thoughts?

[pajod]

Goals:

1. simplify code that was not serving a role in understanding low-level issues
2. make tests work on windows (this only eventually, after a few other patches)
3. start running some end-to-end testing in CI, well beyond individual unit tests, that helps with understanding low-level issues

The first goal is to remove code that is difficult to diagnose for purely historical, no longer applicable, reasons. cPython did not offer these shorthands back then. Now it does. We never gained or lost any control over that particular low-level API, because either it will do what we expect, or worse: it will pretend to offer matching API, but with differences only observable elsewhere.

For those cases, I am all in favor of adding a generous amount of verbosity in clearly platform-specific branches e.g. extend error handlers: pajod@7475a75

not depend on how one external dev think things should work

Specifically, I would like to stop caring whether Windows thinks one should call incompatible ioctlsocket(fd, FIONBIO, ..) and SetNamedPipeHandleState(fd_to_handle(fd), old_mode | PIPE_NOWAIT, ..) calls for essentially the "same" behavior.