Don't set shared file descriptors to non-blocking

I learned something about Unix today which is probably common knowledge to many people, but was the first time I bumped into it: you shouldn't set shared (or inherited) file descriptors to non-blocking I/O mode.

After using io.launcher library on Unix, the stdin stream became a blocking file descriptor, and thus Factor threads did not run while the listener was waiting for input.

This was happening because the launcher forks, disables non-blocking mode on the stdio descriptors, then execs the child process; trouble is, I didn't realize that the nonblocking flag is shared between the two processes, much like the file pointer is shared.

The correct solution is then to have the Factor VM start a thread which reads from stdin and writes to a pipe. The other end of the pipe can be opened in non-blocking mode and made available to Factor's multiplexer.

On Windows, we already have this problem because the command prompt cannot be used with I/O completion ports. Looks like it is time to implement the threaded blocking I/O and solve this problem on both platforms.