0

just some questions on I/O multiplexing, my textbook says:

The select function blocks until at least one descriptor in the read set is ready for reading. A descriptor k is ready for reading if and only if a request to read 1 byte from that descriptor would not block.

Q1-I dont't understand why read 1 byte from a descriptor might block? isn't that standard IO functions use buffer?

Q2-why not just fork a child process and let the child to do job which might block?

Q3-if I use unbuffered system call read() to read a lot of bytes from two opened files, so they're all blocking(take long long time), so how select() does de-multiplexing?

  • [select(2)](http://man7.org/linux/man-pages/man2/select.2.html) tend to be obsolete. Of course you should read its documentation and also [select_tut(2)](http://man7.org/linux/man-pages/man2/select_tut.2.html). I recommend using [poll(2)](http://man7.org/linux/man-pages/man2/poll.2.html) in new code (since it does not limit the highest file descriptor) – Basile Starynkevitch Jan 08 '19 at 05:49
  • Your question shows a lot of confusion. You really should take several days in reading more. My answer gives several links. – Basile Starynkevitch Jan 08 '19 at 06:12

1 Answers1

1

You are misunderstanding the select(2) man page (and see also select_tut(2)). BTW, you'll better use poll(2) in new code, like this; since select is limiting (by the size of fd_set) the highest file descriptor that it can use (think of the C10K problem).

The select man page defines a file descriptor of your process as ready ...

... if it is possible to perform a corresponding I/O operation (e.g., read(2) without blocking, or a sufficiently small write(2)).

That is, if a file descriptor is such that you could successfully read(2) at least one byte from it, it is a ready file descriptor (for reads). Most of the time, you'll be able to read several bytes from it. A file descriptor from which you cannot read, because a read(2) attempt would block, is not ready so could be called a blocked file descriptor.

There are several cases of a file descriptor being blocked (that is, not ready). The usual one is some network socket(7) or some pipe(7) (or some terminal, see pty(7) and the TTY demystified and be aware of the line discipline) not having any more input. That is why poll (or select, epoll(7), etc...) is needed to code event loops (in particular in widget toolkits for GUI, in Web servers, etc.), since you want to avoid busy polling.

For further explanation, read a good Linux programming book, such as the ALP.

You could also read Operating Systems: Three Easy Pieces to get more knowledge about OSes.

Be aware that stdio(3) is implementing buffered IO (above read(2) and write(2)). See also fflush(3) and setvbuf(3).

See also proc(5) to query programmatically the state of processes (most of them being idle since blocked in IO operations or event loops). Or use ps(1), top(1) (both are using /proc/) in commands.

At last, look into the source code of many free software projects (e.g. web servers, GUI toolkits, etc.). You can find many examples of event loops using select or poll.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • so what's the circumstance that it is not ready to read one byte? –  Jan 08 '19 at 05:57
  • I gave several links. You are misunderstanding something essential. Take several days to read ALP. I feel that an entire book is needed to answer your question. – Basile Starynkevitch Jan 08 '19 at 06:02
  • could you tell me first that what does 'read 1 byte from that descriptor would not block' mean, please? –  Jan 08 '19 at 06:14
  • I already did. Read again my answer (and follow the hyperlinks in it!), and read carefully the documentation, and read the [ALP](http://www.makelinux.net/alp/) book. You need to *spend several days in reading more* (and we cannot do that effort at your place) – Basile Starynkevitch Jan 08 '19 at 06:15