apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Fw: cvs commit: apache-2.0/src/support httpd.exp
Date Sat, 02 Dec 2000 10:13:19 GMT
Sorry, got caught by the Reply All thing again and posted this to new-httpd
only...

david

> > > 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).
>
> +1 on this concept.
>
> >
> > (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.
> >
>
> I think we should be coherent throughout and I think that apr_os_make_*
> makes mroe sense for all the reasons given by Greg and Jeff.  If I have an
> fd and want to treat it as a socket then calling apr_os_make_socket()
makes
> perfect sense and might be more logical/intuitive than apr_put_os_socket.
>
> > 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.
>
> +1on dropping _put in favour of make...
>
> david
>
>
>


Mime
View raw message