On Thu, Nov 09, 2006 at 09:42:10AM +0100, Mladen Turk wrote: > Jim Jagielski wrote: > >>>I know that Bill is looking at a release of APR and > >>>that alternate method would, I think, be better > >>>implemented in APR than directly in httpd... > >> > >>Eww, no thanks. AFAIK the same results can be achieved using existing > >>APR interfaces: a non-blocking apr_socket_recv() passing the MSG_PEEK > >>flag, as I mentioned this on [EMAIL PROTECTED] already. > > > >I was referring to an APR apr_is_socket_connected() > >function. Seems to me that it's a common enough > >network "test" that providing it directly with an > >APR call is niceness. > > Can we have that additional function in 1.2.8, > or it's for the trunk only (1.3)?
New functions can only be added in minor version bumps. > Also think apr_socket_is_connected would be name > that would follow the function naming convention. 1) it's a really horrible name. "connected"ness of a socket usually relates to whether or not a connect() has completed. You are really trying to find out whether the socket is still in the ESTABLISHED state here. And you cannot even definitively answer the question "Is this socket in the ESTABLISHED state?". 2) it's a really bad implementation. You can do the same thing portably by doing a poll() and a recv(,MSG_PEEK) AFAICT. There is no need to muck about with ioctls, and it can be done already without adding anything to APR. 2. b) using select() like that will SIGSEGV on Unix for an fd > FD_SETSIZE. There is no excuse to at least not use apr_poll() joe
