Programming

Hello, I have problems finding clear information about the use of select(). I want to write an application, and for that I need to be sure about the functions behaviour. So to ensure, that I understood it all correctly I make some statements or questions. So a qualified answer could just be: yes, you are right in all points.

The manpage says:

"Three independent sets of descriptors are watched. Those listed in readfds will be watched to see if characters become available for reading (more precisely, to see if a read will not block - in particular, a file descriptor is also ready on end-of-file), those in writefds will be watched to see if a write will not block, and those in exceptfds will be watched for exceptions. On exit, the sets are modified in place to indicate which descriptors actually changed status."

So if I read() from a file after select() says it would not block, it will under no circumstances block, right? When I try to read 1 MB, which might not be available without blocking, read() would then just return the data that is available (it has the liberty to read less bytes then I told it to), right? A second read() after that, on the other hand could block, because read has not the liberty to return 0 bytes, because that would mean EOF.

The same thing with write(): When select() says a file is writable, a write() to that file would under no circumstances block. But write might have a size limit, that is unknown to me. So when I write 1MB, it uses the data to fill some internal kernel buffer, and might return without actually writing all the data, but only part of it. It would take only that much data, that is possible to take without blocking. So the first write does under no circumstances block, but the second write could block.

Of course a read() or write() could block, if someone else (another thread/process) does the first read/write after the select, but thats not what I'm interested in, because I don't need to share files with someone else.

Does all this still hold completely true with sockets?

Does all this still hold completely true without using non blocking I/O?

Is it always possible to safely assume, that the first write() after opening a socket/file will not block even without checking this with select()?

The reason why I am not 100% sure about all that is that I did some googling, and some people in some forums says that one can never be 100% sure, if a read/write won't block, even with select, when not using O_NONBLOCK. Some say, that a write does block, if the size is bigger then some magic value. Also most texts about select don't really cover that write case.

Of course I could just use nonblocking I/O to be sure, but I want to make my app as simple as possible, and I don't want to have a "double net" if it is not required.

"Under no circumstances" does not apply to slow read & write devices. There are no guarantees there, as far as I know.

Why are you not using aio? aio_write(), etc. Instead of worrying about all this. aio_read & aio_write calls do not block. They complete and then fail later if there was a serious system problem, or they terminate early if you call aio_cancel. But they do not block. This applies to POSIX-conformant OSes only.

See the opengroup on aio_write:
aio_write

The aio calls were designed so that you call them whenever, then come back later to get the results. This design precludes blocking. They are asynchronous in the best sense.

hmm... If this doesn't apply to slow devices, then what is select() for anyway? If I am working with a fast device, I wouldn't need it in the first place.

I know I could use async. or nonblocking I/O instead. But I thought that select() was there as a "third choice" to avoid blocking.

select works fine, it is the slow devices that are the problem. select or maybe poll are defacto choices for sockets.

Are you going to use sockets with tape drives?

I don't want to use tape drives. But the term "slow device" is relative. Even with a fast device, a read can block, even if it is only about a few milliseconds. In that case I can use select to watch multiple file descriptors, so that one read/write operation doesn't have to wait on another.

I want to use select for sockets and for ordinary hard disk files. I want to have my whole application centered around a select call, that should be the only blocking call in the whole app. Like the event loop in an event-driven application. And the way I read the select man page, this should be possible even with slow devices under all circumstances, even without any nonblocking or async call, and also without multithreading. Because even with a slow device, select should report it "ready" only, when there is something to read/write. So with a slow device, this would happen later, but when the time comes, it should not block.

Is this right? If not, where am I wrong?

If you're using Linux look at select_tut(2)...

Cheers,Steve

The select man page says: "A descriptor is considered ready for writing when a call to an output function with O_NONBLOCK clear would not block, whether or not the function would transfer data successfully."

If you decide to set O_NONBLOCK, the read call will not return until all of the data you requested is available. If this might take any finite amount of time, even several minutes, the device is called "fast". If it might block for all eternity, the device is called "slow". Slow devices include terminals, raw network devices, and IPC psuedo devices.

If you select on a terminal and I am typing on it, select returns on the first character. If you then do a blocking read for 10 characters, you will block until I type nine more. I really can't imagine any alternative behavior.