Harrie Hazewinkel <[EMAIL PROTECTED]> writes:
> APR_DECLARE(apr_status_t) apr_sockaddr_info_get(apr_sockaddr_t **sa,
> const char *hostname,
> apr_int32_t family,
> apr_port_t port,
> apr_int32_t flags,
> apr_pool_t *p);
>
> This is a 'get' function where I believe it is more 'set'.
FWIW the name comes from getaddrinfo()...
it "gets" info from the DNS when needed; it doesn't merely fill in
(set) the fields of the structure
> 2) From apr_network_io.h file.
> /**
> * Create a socket.
> * @param new_sock The new socket that has been set up.
> * @param family The address family of the socket (e.g., APR_INET).
> * @param type The type of the socket (e.g., SOCK_STREAM).
> * @param cont The pool to use
> */
> APR_DECLARE(apr_status_t) apr_socket_create(apr_socket_t **new_sock,
> int family, int type,
> apr_pool_t *cont);
>
> This function together with previous I see this as unfortenate where
> you cannot have made the new_sock and sa can never be made outside these
> functions.
Why would you want to allocate the new_sock yourself? To save some
instructions? This is the way most all of APR works. IMHO it gets
your app running sooner with less problems and it makes it easy to
make all sorts of fixes to APR without breaking binary compatibility.
As far as creating an apr_sockaddr_t otherwise, that type isn't opaque
(mostly so we don't need a bazillion accessor functions to get at all
the info) so you can create it how you wish.
> In some cases it would be more easy to provide these variables already
> without allocating them from a pool. Usage now is always now via a
> pointer indirection which is not needed.
That is APR in general, I'm afraid. But while it bothers me sometimes
it is nice other times.
>
> For instance, you could use the apr_network stuff in a 'big'-function
> call where all variables are declared and not dynamically allocated.
But these objects point to dynamically allocated storage too. It
would be problematic for the APR app to handle that correctly.
Meanwhile, pools are pretty quick.
> Also this can now not being used in an environment where you do not
> always have a apr_pool_t available.
APR in general, again. If you don't *want* a pool mentality it sucks,
but when you give in and develop that side of your brain you can
actually take advantage of them for all aspects of your app
(establishing the right lifetime for stuff without having to
explicitly clean things up on the multiple paths which get you to the
end of that lifetime).
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
