how to get non-blocking file descriptors from a popen?

[Donn Cave]

Quoth Kragen Sitaker <kragen at pobox.com>:
| "Donn Cave" <donn at u.washington.edu> writes:
|> You know,
|> - select & poll really use a file "descriptor" - they'll accept various
|>   alternatives, but only when there's a callable fileno attribute to
|>   return the file descriptor.  And when you go that way, any input
|>   through a file object is liable to buffer up data that select can't
|>   see, so the file object is little or no use.  Use os.read() instead.
|
| Isn't there a way to fix this?

If you don't mind that data will henceforth be read into the buffer
one byte at a time, you can disable buffering.  That won't impose an
egregious extra system load unless you have a lot of data, but it's
kind of a lame notion as far as I'm concerned.  Steel toed boots are
a good idea if you're convinced you need to shoot yourself in the foot.
I'd rather use os.read(), if I don't want the buffering.

|> - when you use select, that file descriptor does _not_ need to be
|>   non-blocking.  select's whole purpose is to tell you when I/O will
|>   not block, so if you let it tell you when to read, non-blocking is
|>   irrelevant.
|
| I always set non-blocking mode anyway, because I've run into problems
| when I don't in the past.  I seem to recall that either read or write
| or both will try to read or write more than is possible and will end
| up blocking unless you mark the fd nonblocking.  Also, on some
| operating systems, some file descriptors can become readable
| temporarily and then become unreadable again (i.e. reads will block).
| So, all in all, it's best to treat select()'s results as a hint, and
| use non-blocking I/O as a backup.

Could be.  I don't write for the operating system I think you're
talking about.  If select reports that there's data to read, and
read() blocks, you have a broken select, so it's hard to say what
it's good for.

	Donn Cave, donn at u.washington.edu