You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2000/12/03 15:27:45 UTC
[PATCH] apr_make_os_sock()
Hopefully I didn't miss any comments on the mailing list last night
(where is that archive again?).
Here is enough to look at to make sure I didn't screw anything up. I
added family and type parameters too so that APR doesn't have to bend
over backwards (i.e., use syscalls) to find that out. We don't keep
the type anywhere yet but it is likely to become useful in the future.
Index: include/apr_portable.h
===================================================================
RCS file: /home/cvspublic/apr/include/apr_portable.h,v
retrieving revision 1.40
diff -u -r1.40 apr_portable.h
--- include/apr_portable.h 2000/11/26 03:00:03 1.40
+++ include/apr_portable.h 2000/12/03 14:28:26
@@ -275,6 +275,23 @@
apr_pool_t *cont);
/**
+ * Create a socket from an existing descriptor and local and remote
+ * socket addresses.
+ * @param apr_sock The new socket that has been set up
+ * @param os_sock The os representation of a socket
+ * @param local The local socket address (or NULL if unknown)
+ * @param remote The remote socket address (or NULL if unknown)
+ * @param family The address family of the socket (e.g., APR_INET)
+ * @param type The type of the socket (e.g., SOCK_STREAM)
+ * @param cont The pool to use
+ * @tip If you only know the descriptor/handle or if it isn't really
+ * a true socket, use apr_put_os_sock() instead.
+ */
+apr_status_t apr_make_os_sock(apr_socket_t **apr_sock, apr_os_sock_t *os_sock,
+ struct sockaddr *local, struct sockaddr *remote,
+ int family, int type, apr_pool_t *cont);
+
+/**
* Convert the lock from os specific type to apr type
* @param lock The apr lock we are converting to.
* @param thelock The os specific lock to convert.
Index: network_io/unix/sockets.c
===================================================================
RCS file: /home/cvspublic/apr/network_io/unix/sockets.c,v
retrieving revision 1.65
diff -u -r1.65 sockets.c
--- network_io/unix/sockets.c 2000/11/21 21:33:07 1.65
+++ network_io/unix/sockets.c 2000/12/03 14:28:28
@@ -282,6 +282,32 @@
return APR_SUCCESS;
}
+apr_status_t apr_make_os_sock(apr_socket_t **apr_sock, apr_os_sock_t *os_sock,
+ struct sockaddr *local, struct sockaddr *remote,
+ int family, int type, apr_pool_t *cont)
+{
+ alloc_socket(apr_sock, cont);
+ set_socket_vars(*apr_sock, family);
+ (*apr_sock)->timeout = -1;
+ (*apr_sock)->socketdes = *os_sock;
+ if (local) {
+ memcpy(&(*apr_sock)->local_addr->sa.sin, local,
+ (*apr_sock)->local_addr->salen);
+ }
+ else {
+ (*apr_sock)->local_port_unknown = (*apr_sock)->local_interface_unknown = 1;
+ }
+ if (remote) {
+#ifndef HAVE_POLL
+ (*apr_sock)->connected = 1;
+#endif
+ memcpy(&(*apr_sock)->remote_addr->sa.sin, local,
+ (*apr_sock)->remote_addr->salen);
+ }
+
+ return APR_SUCCESS;
+}
+
apr_status_t apr_put_os_sock(apr_socket_t **sock, apr_os_sock_t *thesock,
apr_pool_t *cont)
{
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] apr_make_os_sock()
Posted by Jeff Trawick <tr...@bellsouth.net>.
Jeff Trawick <tr...@bellsouth.net> writes:
> +apr_status_t apr_make_os_sock(apr_socket_t **apr_sock, apr_os_sock_t *os_sock,
> + struct sockaddr *local, struct sockaddr *remote,
> + int family, int type, apr_pool_t *cont)
> +{
...
> + memcpy(&(*apr_sock)->remote_addr->sa.sin, local,
> + (*apr_sock)->remote_addr->salen);
> + }
add code for pool cleanup here :)
> +
> + return APR_SUCCESS;
> +}
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] apr_make_os_sock()
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Dec 03, 2000 at 09:27:45AM -0500, Jeff Trawick wrote:
> Hopefully I didn't miss any comments on the mailing list last night
> (where is that archive again?).
>
> Here is enough to look at to make sure I didn't screw anything up. I
> added family and type parameters too so that APR doesn't have to bend
> over backwards (i.e., use syscalls) to find that out. We don't keep
> the type anywhere yet but it is likely to become useful in the future.
Seems fine to me!
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] apr_make_os_sock()
Posted by rb...@covalent.net.
> > Won't it need to be different on different platforms? I mean, Windows
> > wants a SOCKET, and I wouldn't put it past M$ to change the sockaddr to
> > some windows specific structure in the future.
>
> The prototype will be the same... that is why we have the apr_os_sock_t
> type.
>
> We shouldn't need to pass structures to apr_make_os_socket() (or other,
> similar creation functions).
Look again Greg. The lock stuff already uses structures, because the
amount of information required for creating locks is different based on
the type of lock. That's where structures really help, and why I would
rather see these functions using structures. It allows us a bit more
flexability with regard to the different types we can accept.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] apr_make_os_sock()
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Dec 03, 2000 at 11:38:32AM -0800, rbb@covalent.net wrote:
>
> > > > Here is enough to look at to make sure I didn't screw anything up. I
> > > > added family and type parameters too so that APR doesn't have to bend
> > > > over backwards (i.e., use syscalls) to find that out. We don't keep
> > > > the type anywhere yet but it is likely to become useful in the future.
> > >
> > > I would really prefer that this function at least look like the current
> > > apr_put_os_* functions. That would mean just wrapping all of this
> > > information up into a single structure that is just passed to APR's create
> > > function.
> >
> > What is the purpose of putting the parameters into a structure? Do we
> > expect that we'll want to tailor the information provided to
> > apr_make_os_socket() on certain platforms?
>
> Won't it need to be different on different platforms? I mean, Windows
> wants a SOCKET, and I wouldn't put it past M$ to change the sockaddr to
> some windows specific structure in the future.
The prototype will be the same... that is why we have the apr_os_sock_t
type.
We shouldn't need to pass structures to apr_make_os_socket() (or other,
similar creation functions).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] apr_make_os_sock()
Posted by rb...@covalent.net.
> > > Here is enough to look at to make sure I didn't screw anything up. I
> > > added family and type parameters too so that APR doesn't have to bend
> > > over backwards (i.e., use syscalls) to find that out. We don't keep
> > > the type anywhere yet but it is likely to become useful in the future.
> >
> > I would really prefer that this function at least look like the current
> > apr_put_os_* functions. That would mean just wrapping all of this
> > information up into a single structure that is just passed to APR's create
> > function.
>
> What is the purpose of putting the parameters into a structure? Do we
> expect that we'll want to tailor the information provided to
> apr_make_os_socket() on certain platforms?
Won't it need to be different on different platforms? I mean, Windows
wants a SOCKET, and I wouldn't put it past M$ to change the sockaddr to
some windows specific structure in the future.
> I guess I'm not sure what you mean by "APR's create function..." Do
> you want to change apr_create_socket() to take parameters in a
> structure, and have the structure indicate whether or not we already
> have the OS socket (I don't think this is what you mean).
I meant apr_make_os_socket when I said the create function.
> Should it be apr_make_socket() instead of apr_make_os_socket()?
No. This is a portability function, and it should retain the os in the
name.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] apr_make_os_sock()
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> On Sun, 3 Dec 2000, Jeff Trawick wrote:
>
> > Hopefully I didn't miss any comments on the mailing list last night
> > (where is that archive again?).
> >
> > Here is enough to look at to make sure I didn't screw anything up. I
> > added family and type parameters too so that APR doesn't have to bend
> > over backwards (i.e., use syscalls) to find that out. We don't keep
> > the type anywhere yet but it is likely to become useful in the future.
>
> I would really prefer that this function at least look like the current
> apr_put_os_* functions. That would mean just wrapping all of this
> information up into a single structure that is just passed to APR's create
> function.
What is the purpose of putting the parameters into a structure? Do we
expect that we'll want to tailor the information provided to
apr_make_os_socket() on certain platforms?
I guess I'm not sure what you mean by "APR's create function..." Do
you want to change apr_create_socket() to take parameters in a
structure, and have the structure indicate whether or not we already
have the OS socket (I don't think this is what you mean).
Should it be apr_make_socket() instead of apr_make_os_socket()?
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] apr_make_os_sock()
Posted by rb...@covalent.net.
On Sun, 3 Dec 2000, Jeff Trawick wrote:
> Hopefully I didn't miss any comments on the mailing list last night
> (where is that archive again?).
>
> Here is enough to look at to make sure I didn't screw anything up. I
> added family and type parameters too so that APR doesn't have to bend
> over backwards (i.e., use syscalls) to find that out. We don't keep
> the type anywhere yet but it is likely to become useful in the future.
I would really prefer that this function at least look like the current
apr_put_os_* functions. That would mean just wrapping all of this
information up into a single structure that is just passed to APR's create
function.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------