Messages in this thread | | | From | "Robert White" <> | Subject | RE: UDP recvmsg blocks after select(), 2.6 bug? | Date | Fri, 15 Oct 2004 15:42:55 -0700 |
| |
-----Original Message----- From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Willy Tarreau
> As I asked in a previous mail in this overly long thread, why not returning > zero bytes at all. It is perfectly valid to receive an UDP packet with 0
Zero bytes is "end of file". Don't go trying to co-opt end of file. That way lies madness and despair.
You would *then* need a flag on each file descriptor to determine if the most previous call before the read op was a select that returned the file as readable so you knew whether to block or return the not-really-end-of-file. Your *app* would then also need a flag/context to determine whether the end of file just read was contextually an aborted read after select.
Nope, very very very very very bad idea... 8-)
[On the larger issues, I am surprised that select() doesn't guarantee available data and one subsequent non-blocking read, but again in the case of a UDP discard after the select but before the read, that is the only thing that makes sense. I would vote (were this a democracy 8-) to put a CAVEAT in the manual that listed the _rare_ cases, as examples, where the warrant of available data may prove false; give a nod to real life, and _firmly suggest_ that if you are using select, you *probably* want nonblocking file descriptors too.]
- 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/
| |