Update comments on some Windows test issues that are better understood. [skip ci]

src/greentest/known_failures.py

@@ -34,11 +34,14 @@ FAILING_TESTS = [
 
 
 if sys.platform == 'win32':
+    IGNORED_TESTS = [
+        # fork watchers don't get called on windows
+        # because fork is not a concept windows has.
+        # See this file for a detailed explanation.
+        'test__core_fork.py',
+    ]
     # other Windows-related issues (need investigating)
     FAILING_TESTS += [
-        # fork watchers don't get called in multithreaded programs on windows
-        # No idea why.
-        'test__core_fork.py',
         'FLAKY test__greenletset.py',
         # This has been seen to fail on Py3 and Py2 due to socket reuse
         # errors, probably timing related again.
@@ -95,8 +98,8 @@ if sys.platform == 'win32':
 
     if not PY35:
         # Py35 added socket.socketpair, all other releases
-        # are missing it
-        FAILING_TESTS += [
+        # are missing it. No reason to even test it.
+        IGNORED_TESTS += [
             'test__socketpair.py',
         ]
 

src/greentest/test__core_fork.py

@@ -2,7 +2,7 @@ from __future__ import print_function
 import gevent.monkey; gevent.monkey.patch_all()
 import gevent
 import os
-import sys
+
 import multiprocessing
 
 hub = gevent.get_hub()
@@ -48,4 +48,10 @@ if __name__ == '__main__':
     # fork watchers weren't firing in multi-threading processes.
     # This test is designed to prove that they are.
     # However, it fails on Windows: The fork watcher never runs!
+    # This makes perfect sense: on Windows, our patches to os.fork()
+    # that call gevent.hub.reinit() don't get used; os.fork doesn't
+    # exist and multiprocessing.Process uses the windows-specific _subprocess.CreateProcess()
+    # to create a whole new process that has no relation to the current process;
+    # that process then calls multiprocessing.forking.main() to do its work.
+    # Since no state is shared, a fork watcher cannot exist in that process.
     test()