> > 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 sense. > > 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 apr_get_os_*. > > 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 _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
