apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: Time for 2.2.4?
Date Thu, 09 Nov 2006 15:53:13 GMT
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 dev@apr 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()


View raw message