You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Greg Stein <gs...@lyra.org> on 2000/12/02 03:08:08 UTC
Re: cvs commit: apache-2.0/src/support httpd.exp
On Fri, Dec 01, 2000 at 05:39:05PM -0800, rbb@covalent.net wrote:
> > > Unfortunately, after getting the normal code working I went into the
> > > WinNT MPM ('cause it too calls ap_new_connection()) and realized I
> > > needed to do some research about whether or not the APR socket (built
> > > via apr_put_os_sock()) is properly initialized on Windows.
> >
> > We should probably toss the apr_put_os_* functions and call them something
> > like apr_os_make_*() and accept the particular OS object to construct the
> > APR type.
>
> 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.
Basically, it seems to make more sense to build an APR object around an
OS-specific object, rather than to try and build an APR object and inject
the OS piece.
> 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.
> 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."
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/support httpd.exp
Posted by David Reid <dr...@jetnet.co.uk>.
> > 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
Re: cvs commit: apache-2.0/src/support httpd.exp
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 01, 2000 at 06:37:00PM -0800, rbb@covalent.net 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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/support httpd.exp
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Dec 01, 2000 at 06:37:00PM -0800, rbb@covalent.net 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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/support httpd.exp
Posted by rb...@covalent.net.
> 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). 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.
So, IMHO we want apr_put_os_* for all APR types and apr_os_make_* only for
those types that have conditions like socket.
Does that make sense?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/support httpd.exp
Posted by rb...@covalent.net.
> 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). 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.
So, IMHO we want apr_put_os_* for all APR types and apr_os_make_* only for
those types that have conditions like socket.
Does that make sense?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/support httpd.exp
Posted by rb...@covalent.net.
> > 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 rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apache-2.0/src/support httpd.exp
Posted by rb...@covalent.net.
> > 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 rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------