| msg316067 - (view) |
Author: Filip Š (filips123) * |
Date: 2018-05-02 10:35 |
| Unix socket (AF_UNIX) is now avalible in Windows 10 (April 2018 Update). Please add Python support for it. More details about it on https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-windows/ |
|
|
| msg347629 - (view) |
Author: Paul Monson (Paul Monson) * |
Date: 2019-07-10 18:06 |
| I've been asked by my team to investigate what is required to enable AF_UNIX in Python. Is anyone else actively investigating this? I did a prelinary investigation and the impact on test in test_sockets was pretty simple. However there were 26 test failures in test_asyncio tests, with only the naive changes to all AF_UNIX to work with the socket class on Windows. The first failure I looked at was caused by ProactorEventLoop in windows_events.py not providing a windows-specific version of create_unix_server. This results in the code falling back to AbstractServer.create_unix_server which raises NotImplementedError. |
|
|
| msg347645 - (view) |
Author: Ma Lin (malin) * |
Date: 2019-07-11 00:21 |
| Have you upgraded the building SDK that supports AF_UNIX? And should remove AF_UNIX flag at runtime on systems older than Windows 10 1804, see . |
|
|
| msg347646 - (view) |
Author: Ma Lin (malin) * |
Date: 2019-07-11 00:43 |
| It would be nice to investigate the habit of using AF_UNIX in Python code on GitHub: https://github.com/search?l=Python&q=AF_UNIX&type=Code If adding this flag will break a lot of code, due to lacking supports to datagram, maybe we should not add AF_UNIX at once, and waiting for full support to AF_UNIX. |
|
|
| msg348080 - (view) |
Author: Paul Monson (Paul Monson) * |
Date: 2019-07-17 19:18 |
| I don't know if datagram support is coming to AF_UNIX on Windows. The changes will only add the flag on Windows, and will enable stream sockets to use AF_UNIX on Windows. In mind this isn't breaking datagram support. It is true that it's a subset of what appears to be supported on Linux/Unix. |
|
|
| msg348880 - (view) |
Author: Ma Lin (malin) * |
Date: 2019-08-02 01:12 |
| The current AF_UNIX address family of Windows10 doesn't support datagram, adding this flag may break some cross-platform code: https://github.com/osbuild/osbuild/blob/9371eb9eaa3d0a7cab876eb4c7b70f519dfbd915/osbuild/__init__.py#L253 https://github.com/watsona4/dot_julia2/blob/5b7632b8089be01af706d8152555e711e0a81f06/conda/3/pkgs/python-3.7.3-h0371630_0/lib/python3.7/logging/handlers.py#L676 https://github.com/bognikol/Eleusis/blob/828672492b9cdb3444ddf466c0ac3055572277f7/Dependencies/02_macOS/40_gtk%2B/x64/lib/python2.7/test/test_socketserver.py#L177 https://github.com/sarnautov/python3/blob/005d75d8ac2b11a06707ce0184021a727d6fe844/lib/python3.6/test/test_asyncio/test_unix_events.py#L311 https://github.com/yanlianglai/ssr_python_leeblog/blob/8113fe3f32a250cc52e0cddad9761692dd840967/shadowsocks/manager.py#L60 ... So I'm -1 on adding AF_UNIX personally. I thought a compromise proposal: - if (building SDK >= 1804 and run-time Windows >= 1804), add a undocumented flag _WIN_AF_UNIX, its value is equal to AF_UNIX. - only use _WIN_AF_UNIX in stdlib, this is a black-box optimization. - if someone really need high performance, he/she can uses this undocumented flag privately. If one day Windows support full AF_UNIX, we can remove _WIN_AF_UNIX and add standard AF_UNIX. |
|
|
| msg348913 - (view) |
Author: Steve Dower (steve.dower) *  |
Date: 2019-08-02 20:25 |
| Most of those examples would break today if run on Windows, though (AttributeError). So they'd just continue to break, probably with a different error (I'm not clear what happens if we specify SOCK_DGRAM with this change). Having an undocumented field doesn't really help much - what we want is a documented field with a different name, perhaps WIN_AF_UNIX? (I think we need to keep the "AF_" prefix for real values and not mess up the namespace ourselves.) That way we can document that it matches AF_UNIX when defined on Windows, but will not trigger existing code that checks for the presence of AF_UNIX. Then we'll have to update the standard library to use either/both values where supported. |
|
|
| msg348923 - (view) |
Author: Paul Monson (Paul Monson) * |
Date: 2019-08-02 22:17 |
| If you try to create a datagram socket with the current AF_UNIX changes on Windows the error is: OSError: [WinError 10047] An address incompatible with the requested protocol was used All of the examples given will fail to load with AttributeError on Windows because socket.AF_UNIX is not a valid attribute on Windows. I think it's possible that there is code that detects whether AF_UNIX is an attribute on socket or not and does something different on Windows, but I haven't seen an example of it so far. I can make the changes to WIN_AF_UNIX when I continue working on this, just in case there is portable code out there somewhere. |
|
|
| msg348936 - (view) |
Author: Steve Dower (steve.dower) * |
Date: 2019-08-03 00:53 |
| > I think it's possible that there is code that detects whether AF_UNIX is an attribute on socket or not and does something different on Windows, but I haven't seen an example of it so far. One of the test suites linked above had a skipUnless(hasattr(socket, 'AF_UNIX')) on the whole class, and at least one test assumed that it could use datagram support, so there's the example. |
|
|