apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: [PATCH] APR Socket IOL
Date Thu, 08 Nov 2001 19:44:45 GMT
On Thursday 08 November 2001 10:02 am, Bill Stoddard wrote:
> > On Thu, Nov 08, 2001 at 10:32:45AM -0500, Bill Stoddard wrote:
> > > This patch is a first rough implementation of a socket iol in APR (from
> > > discussions
>
> with
>
> > > Sander Striker a few months back).
> > >
> > > Public API Changes:
> > > No new APIs were created.
> > > apr_socket_create() has an extra parameter, a pointer to an
> > > apr_socket_iol_t.
> > >
> > > New Public Structures:
> > > apr_socket_iol_t - contains pointers to callback functions.
> > >
> > > Usage:
> > > If you do not want to redirect socket calls and just use existing APR
> > > calls, use apr_socket_create() thusly:
> > > apr_socket_create(&new_sock, APR_INET, SOCKSTREAM, NULL, r->pool);
> >
> > I thought we were trying to move away from function pointers because
> > people thought they were slow.  Could/should we create a parallel API
> > for this instead?  -- justin
>
> If we created a parallel API, the all of the HTTP Server (for example)
> apr_socket calls would have to be migrated to this new API; seems rather
> pointless. Adding a lot of complexity to the API just to avoid one function
> call.
>
> Yep, adding another function call/level of indirection chews a bit of CPU
> but it is not that big a deal overall. And in the common case, we will
> -not- be making socket calls via function pointers. In the common case, we
> just make a direct function call. Only when we want to redirect the
> function calls will we use the function pointers.

Why would HTTP use this at all?  With filters, this concept isn't necessary
any more.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message