Failing subprocess test on Windows

[gbtami]

C:\gbulb\tests>pytest -v

platform win32 -- Python 3.4.4, pytest-3.0.7, py-1.4.33, pluggy-0.4.0 -- c:\python34\python.exe
cachedir: ..\.cache
rootdir: C:\gbulb, inifile:
collected 48 items

test_glib_events.py::TestGLibEventLoopPolicy::test_set_child_watcher PASSED
test_glib_events.py::TestGLibEventLoopPolicy::test_new_event_loop PASSED
test_glib_events.py::TestGLibEventLoopPolicy::test_new_event_loop_application PASSED
test_glib_events.py::TestGLibHandle::test_attachment_order PASSED
test_glib_events.py::TestBaseGLibEventLoop::test_add_signal_handler SKIPPED
test_glib_events.py::TestBaseGLibEventLoop::test_remove_signal_handler SKIPPED
test_glib_events.py::TestBaseGLibEventLoop::test_remove_signal_handler_unhandled SKIPPED
test_glib_events.py::TestBaseGLibEventLoop::test_remove_signal_handler_sigkill SKIPPED
test_glib_events.py::TestBaseGLibEventLoop::test_remove_signal_handler_sigill SKIPPED
test_glib_events.py::TestBaseGLibEventLoop::test_run_until_complete_early_stop PASSED
test_glib_events.py::TestBaseGLibEventLoop::test_add_writer SKIPPED
test_glib_events.py::TestBaseGLibEventLoop::test_add_reader SKIPPED
test_glib_events.py::TestBaseGLibEventLoop::test_add_reader_file SKIPPED
test_glib_events.py::TestBaseGLibEventLoop::test_add_writer_file SKIPPED
test_glib_events.py::TestBaseGLibEventLoop::test_remove_reader SKIPPED
test_glib_events.py::TestBaseGLibEventLoop::test_remove_writer SKIPPED
test_glib_events.py::TestBaseGLibEventLoop::test_time PASSED
test_glib_events.py::TestBaseGLibEventLoop::test_call_at PASSED
test_glib_events.py::TestBaseGLibEventLoop::test_call_soon_no_coroutine PASSED
test_glib_events.py::TestBaseGLibEventLoop::test_call_later_no_coroutine PASSED
test_glib_events.py::TestBaseGLibEventLoop::test_call_at_no_coroutine PASSED
test_glib_events.py::TestBaseGLibEventLoop::test_call_soon_priority_order PASSED
test_glib_events.py::TestBaseGLibEventLoop::test_call_soon_priority PASSED
test_glib_events.py::TestBaseGLibEventLoop::test_add_writer_multiple_calls SKIPPED
test_glib_events.py::TestBaseGLibEventLoop::test_call_soon_threadsafe PASSED
test_glib_events.py::TestGLibEventLoop::test_run_forever_recursion PASSED
test_glib_events.py::TestGLibEventLoop::test_run_recursion PASSED
test_glib_events.py::TestGLibEventLoop::test_run PASSED
test_glib_events.py::TestGLibEventLoop::test_stop PASSED
test_glib_events.py::TestGLibEventLoop::test_set_application PASSED
test_glib_events.py::TestGLibEventLoop::test_set_application_invalid_type PASSED
test_glib_events.py::TestGLibEventLoop::test_set_application_invalid_repeat_calls PASSED
test_glib_events.py::TestGLibEventLoop::test_set_application_invalid_when_running PASSED
test_glib_events.py::test_default_signal_handling SKIPPED
test_glib_events.py::test_subprocesses_read_after_closure

It's waiting forever at this point.

[gbtami]

I'm just learning this asyncio stuff, so it's possible what I say is totally dumb, but isn't GLib.spawn_async() should be used instead of subprocess.Popen() in SubprocessTransport somehow?

[nhoad]

Yes! That's part of it at least, though if we really wanted we could keep using subprocess.Popen. The part I'm having the most difficulty with at the moment is that on Windows, anonymous pipes (e.g. those created to communicate with subprocesses) don't seem to support non-blocking reads, so the channel.read() call blocks. I'm not sure what can actually be done to fix this, short of hacking IOCP support in and using that for these pipes :/

@Alexander255, do you have any ideas on what could be done here?

[AstraLuma]

Nope, Windows pipes don't work with windows select. I think you have to use overlapped reads.

(I might have had to look into this working on xonsh/xonsh and xonsh/slug.)

[ldo]

Seems like the pipe limitation is a bug in Windows that Microsoft should fix. After all, the Cygwin folks figured it out; why can’t Microsoft?

[freakboy3742]

Pretty sure this is covered by the "Gbulb doesn't support Windows" caveat on the README.

I'm very much open to a PR that addresses this (although #32 would also need to be addressed); but until the project actually claims support for Windows, reporting bugs in Windows support isn't reasonable.