Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3FCFD99D.1060402@attglobal.net>
Date: Thu, 04 Dec 2003 20:04:29 -0500
From: Jeff Trawick <trawick@attglobal.net>
Reply-To: trawick@attglobal.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: Patches for bug found in APR sockets
References: <3FB91EA3.9020508@opendemand.com>
 <3FC21A41.1020501@opendemand.com> <3FCCB2A5.1050005@attglobal.net>
In-Reply-To: <3FCCB2A5.1050005@attglobal.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Jeff Trawick wrote:

> The interesting question IMO is can we get rid of the unfortunate 
> overhead -- the preallocation of sockaddrs at socket creation time.  I 
> believe that is required to support the ancient ideom
> 
>    apr_socket_create(&sock);
>    apr_socket_addr_get(&remote_addr, REMOTE, sock);
>    apr_sockaddr_ip_set(remote_addr, "1.2.3.4");
>    apr_sockaddr_port_set(remote_addr, 80);
>    apr_connect(sock, NULL);
> 
> I'll start a new thread on some networking apis to remove and give folks 
> a chance to holler.  Once that is resolved, I suspect you'll find that 
> the unfortunate overhead is now worthless, and some alternative patch 
> can clean up that issue.

sockaddr_ip_set(), sockaddr_port_set() are now gone...  now is prime time to 
see if there is any remaining need to allocate those sockaddrs, and separately 
to see if any well known APR users somehow rely on those sockaddrs being 
preallocated (i.e., they grab local socket address from socket before it would 
necessarily be set)