You are doing something wrong. You are using 'select' along with blocking
I/O operations. You can't make bricks without clay. If you don't want to
block, you must use non-blocking socket operations. End of story.
Just because 'select' indicates a write hit, you are not assured that some
particular write at a later time will not block. Past performance does not
guarantee future results.
Suppose, for example, a machine has two network interfaces. One is very
busy, queue full, and one is totally idle, queue empty. What do you think
'select' for write on an unconnected UDP socket should do? If you say it
should block, then it can block forever even if there's plenty of buffer
space on the network card you were going to send to. So, it can't block, it
must indicate writability.
Now, tell me what a blocking UDP write should do if the buffer is full.
Should it return success but drop the packet silently? Does that seem right
to you?
You have any number of sane choices. My suggestion is that you make the
socket non-blocking and treat an EWOULDBLOCK return as equivalent to
success. You can additionally take it as a hint that the packet will be as
if it was dropped.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/