Am Donnerstag, 6. Dezember 2007 09:53 schrieb David Miller:
> > I think the words "shall fail" and "immediately" are quite clear.
>
> They are, but the context in which they apply is vague.
"socket is connection-mode" => SOCK_STREAM
> I can equally generate examples where the non-blocking behavior you
> are a proponent of would break non-blocking UDP apps during a
> sendmsg() call when we hit IPSEC resolution. Yet similar language on
> blocking semantics exists for sendmsg() in the standards.
I am not a good enough kernel hacker to exactly understand the code flow in
udp_sendmsg(). However, it seems that it first checks destination validity
via ip_route_output_flow() and queues the message then. The sendmsg()
documentation only talks about buffer space. I can see your dilemma.
The reason why I'm pushing this issue another time is that I know quite a
bit about system level application development. A very typical design pattern
for non-naive single or multi threaded programs is that they set all
communication sockets to be nonblocking and use a select()/epoll() based loop
to dispatch IO. This often includes initiating a TCP connect() and
asynchronously waiting for it to finish or fail from the main loop.
The dangerous situation here is that in 99% of all cases things will just work
because the phase 2 SA exists. In 0.8%, the SA will be established in <1 sec.
However, in the rest of time the server application that you have considered
to be stable will end up sleeping with all threads in a connect() call that
is supposed to return immediatly.
> The world is shades of gray, implying anything else is foolhardy and
> that's how I'm handling this.
Even though I consider programmers that ignore the result code on a
nonblocking UDP sendmsg() fools, I agree. May be the best compromise is what
Herbert Xu suggested in <[email protected]> in this
thread: At least, for connect() O_NONBLOCK ist ALWAYS respected. Because this
is where the chance for breakage is highest.
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
