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 netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
