Marc Hartmayer

Yep, right now I'm experimenting, especially in regard with the tests. Because it would be great if we have minimal tests for blocking and non-blocking STDIO. So the timeout test...

> By all means continue experimenting if you wish to, but be aware I'm unlikely to accept many new features into this chunk of code - particularly if they increase...

@moreati I've now added two test cases, one that causes an timeout and the other that causes the EOF situation similar to the original bug.

@moreati I've now added one test case that runs the full stage code (`tests.first_stage_test.CommandLineTest.test_stage`). I'm going to add multiple other test cases, e.g. stdin is a blocking FD, stdin is...

@moreati Is there a difference to run test `first_stage_test` via ./run_tests.sh or manually via Python unittest executor? That's the command line I'm using during development: ``` $ PYTHONPATH=$(pwd)/tests:$PYTHONPATH python -m...

> @moreati Is there a difference to run test `first_stage_test` via ./run_tests.sh or manually via Python unittest executor? Okay, I found one difference: MITOGEN_LOG_LEVEL=debug is enabled, that results in a...

@moreati Two questions: 1. Is it okay, if I pick your commit as fix for the timeout situation in this PR (or how should we proceed)? 2. Can we revert...

@moreati I couldn’t come up with a non-racy solution, so I implemented custom dummy connectors that use blocking and non-blocking I/O for STDIN/STDOUT. There is still one unstable test left:...

> I've begun trying variations of your tests in #1392, I'm finishing for the day now but tomorrow or later this week would you like to do a call (e.g....

@moreati I've polished the commits/tests a little so they should be stable on all environments we support (I did not test with Windows Subsystem for Linux (WSL)). The whole series...