httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: cvs commit: apache-2.0/src/support httpd.exp
Date Sat, 02 Dec 2000 03:13:48 GMT
On Fri, Dec 01, 2000 at 06:37:00PM -0800, wrote:
> > 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.
> I have thought about this a bit more, and I think we actually want both
> apr_put_os_* and apr_os_make_* (although I would use apr_make_os_* for
> consistency).

I would tend to agree with that. I'm not sure that losing the "put" makes
perfect sense.

> The reason we want both, is that they have different
> uses.  In the perchild MPM, I really do want apr_put_os_socket, because I
> don't have a full socket, I have a Unix Domain Socket, so I don't want to
> fill out the whole os specific socket structure.  Same thing goes for
> apr_socket_from_file, we can't fill in the whole structure.

Right, but we still need that structure "zeroed". Or it needs to be possible
to get it filled in.

Taking an idea from something Jeff said: when we stuff the socket into the
apr_socket, we need to pass in the sockaddr stuff because we happen to
already have it. To me, that says the "make" function would take these
additional parameters. Pass NULL, and you get the behavior you're looking
for (e.g. the "socket" doesn't have addresses).

(but then we'd need a way to distinguish between "don't have them" and
"these don't apply")

But let's go back to your case about just stuffing an fd into an apr_socket
(where the fd is a Unix socket or a file). Where did the socket come from? I
think it is a bit weird to say "construct a socket object, but not really...
then, we'll put something real into it." I'd rather see different
constructors for the socket: one for a full socket, one for a pseudo-socket,
one for ...

> So, IMHO we want apr_put_os_* for all APR types and apr_os_make_* only for
> those types that have conditions like socket.

"conditions"? not sure that I follow. You mean something like the psuedo-
socket mentioned above? Possibly. I think it just makes more sense to have
different constructors, and let the APR object decide what needs to happen.

I think that is it... apr_put_os_* means that the caller must know about the
internal state(s) of the APR object. I think what we are really trying to
accomplish is "I've got this OS-specific handle, please give me an APR
object that corresponds to it." Currently, the callers "know" they can
create a bare APR type and then stuff the value via apr_put_os_* to get what
they need.

Re: retaining an analogue between "get" and "put" ... I don't think that
applies. In one case, you have an APR object and you want to get the
OS-specific representation. In the "make" case, you have the OS-specific,
but want an APR object. "put" is one small piece of the "make" case, and I
don't think it is quite enough because of the whole issue of needing to know
the internals of the APR object.


Greg Stein,

View raw message