Linux programs often need to access more than one file at the same time. This can require a bit of coordination — or multiplexing — of the I/O. Under normal circumstances, the order in which different files get accessed
by a program is determined by a simple algorithm. For example, the cat command employs the following algorithm to achieve this:
Linux programs often need to access more than one file at the same time. This can require a bit of coordination — or multiplexing — of the I/O. Under normal circumstances, the order in which different files get accessed by a program is determined by a simple algorithm. For example, the cat command employs the following algorithm to achieve this:
1) read some information from standard in
2) write the same information from standard out
3) if standard in still has information, go back to step 1
While there are two files being used here, cat can use normal, blocking I/O and get the job done. If there isn’t any data available in step 1, cat wants to wait around for data to appear anyway — it doesn’t have anything else to do. If a program wanted to do some other work while it was waiting for data to appear on standard in, it could use nonblocking I/O (which I discussed in last month’s issue) and simply check for data at some convenient time. Similarly, if cat can’t write the data out right away (if standard out refers to a pipe that is currently full, for example), then just blocking until the data can be written is perfectly appropriate.
Let’s look at a case where the normal read() and write() paradigm doesn’t work very well. The telnet client, which lets users log into remote machines, has two file descriptors it needs to read from. The first is…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
