apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: cvs commit: apache-2.0/src/support httpd.exp
Date Sat, 02 Dec 2000 02:16:58 GMT

> > Two questions.  1)  Why the name change?  2)  What particular OS object
> > are you talking about?
> 1) To signify that the object is be constructed/built with the OS object (an
>    fd, socket fd, thread id, whatever), rather than simply inserted.
> 2) The case Jeff was running into was sockets. When an fd was inserted into
>    an apr_socket, some of the other stuff wasn't set up.

I know what the issue is we are trying to solve.  So, are you suggesting
that each APR type will have such an object?  If we are only going to do
this for sockets and locks (already doing it for socks), then I would
prefer to just stick with apr_put_os_*.  If we are going to do this for
more APR types, then the apr_os_make_* functions do make more sense,
assuming we can find some way to make the apr_get_os_* functions make

> > The reason I chose the apr_put_os_* name, is that it matches well with
> > apr_get_os_*.
> Right, and that makes sense. But if we need a real "constructor", then
> apr_put_os_* doesn't sound quite right.

I agree, but we still need to find some way to match it up with

> > Not that its important, but I would like the two functions
> > to be symetric, because they perform complimentary functions.
> Yup. And my thinking is that the "put" isn't as useful as a "make a new APR
> object, given this socket fd."

I agree, I'm just asking that if we change the constructor, we also find
some way to change the get function.


Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131

View raw message