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 [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
