unixd_accept

[David Reid <dr...@jetnet.co.uk>]

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.

This also seems to apply for some other defines and functions.

The definition could even be moved to a more central less os specific
setting...

Thoughts?

david

Re: unixd_accept

[Ryan Bloom <rb...@covalent.net>]

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				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Re: unixd_accept

[Justin Erenkrantz <je...@ebuilt.com>]

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

Re: unixd_accept

[Ryan Bloom <rb...@covalent.net>]

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.
> 
> This also seems to apply for some other defines and functions.
> 
> The definition could even be moved to a more central less os specific
> setting...
> 
> Thoughts?

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.

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