- First, there is a clear difference between the raw glibc functions (all in the glibc module) and anything else. You can use them directly just as you would have from C. There's no magic going on and it's all there.
- Second, we now have a growing collection of python wrappers (in the new pyglibc package), that give low-level primitives nice, high-level, pythonic API. Some of those are straight out of Python 3.4 (but are not a code copy), those include selectors.EpollSelector and select.epoll, some are custom (there's nothing to based this on) like signalfd and pthread_sigmask. More are on the way.
- Third, and this is pretty interesting. I've decided to build a PEP3156 compatible event loop API. This is paramount for how this code can be consumed. It should roughly work out of the box as a drop-in replacement for the Python 3.4 only asyncio module. Did I mention that it works on Python 2.7? A lot is still missing but I am making progress. This ultimately means that once my contraption makes it into plainbox it won't have to be supported forever (aka job security) and can be discarded once we can depend on Python 3.4. It also means there's a clear, well defined API, a reference implementation (and some others if you look hard enough.
All of that is coming in the 0.6 release that I plan to make later today. The API is stable as I don't like changing my examples over and over so if you want to give it a try, please do so.
If you're interested in discussing this, using it, adding patches or the like, ping me please.
- timeout (optional, new feature)
- read side of the stdout pipe data
- read side of the stdout pipe being closed
- read side of the stderr pipe data
- read side of the stderr pipe being closed
- SIGCHLD being delivered with the intent to say that the process is dead
- if we still have stdout pipe open, read at most one PIPE_BUF. We cannot read more as the pipe may live on forever and we can just hang as we currently do. Reading one PIPE_BUF ensures that we catch the last moments of what the originally started process intended to tell us. Then we close the pipe. This will likely result in SIGPIPE in any processes that are still attached to it though we have no guarantee that it will rally kill them as that signal can be blocked.
- if we still have stderr pipe open we follow the same logic as for stdout above.
- we restore some signal handling that was blocked during the execution of the loop and terminate.