On Monday 24 December 2001 10:01 am, Justin Erenkrantz wrote: > On Mon, Dec 24, 2001 at 09:00:09AM -0800, Ryan Bloom wrote: > > On Monday 24 December 2001 03:58 am, David Reid wrote: > > > This is defined, but how about we rename it to something without the unixd_ > > > portion so that it's simply a more generic os function, something like > > > ap_os_accept? I ask as I added a beosd_accept and that seems a little > > > clumsy as in the worker MPM I have to then add a series of #if's to get the > > > function used, so simply having an ap_os_accept would solve the problem and > > > seems like an easier way to go. > <snip, snip> > > I have no problem with doing this, but we need to keep this logic out of the > > main server. The whole point of the unixd_* functions is that they don't make > > any sense for Windows, and possibly for OS/2. If you can use all or even > > most of those functions, then why don't you just rename your platform > > to unixd, and abstract out the differences. > > Silly question, but why isn't this a hook that various platforms > can implement? I kind of thought that was the purpose of hooks. > (And, I believe that hooks may not be there, so nothing will run - > perfect for Win32 or OS/2). -- justin
Because it doesn't make any sense as a hook. Each socket type only has one way to accept a connection. The point of hooks is to allow multiple modules a chance to intercept a call, so that the best one can be used. The point of this code is to allow the module that created the socket to add a function that knows how to accept a connection. The code that creates a socket must also know how to accept a connection, or the socket is useless. Remember that hooks have performance implications that means we don't always want them. Ryan ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
