[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apr-dev
Subject:    RE: Local sockets
From:       Karsten Paige Huneycutt <kph () duke ! edu>
Date:       2002-05-23 23:52:35
[Download RAW message or body]

On Wed, 22 May 2002, William A. Rowe, Jr. wrote:

> Realize that this is a HUGE shortcoming for Win32, and functionality 
> that
> we need addressed for Windows.  With no fork() implementation 
> whatsoever,
> we need to be able to pass fd's (apr_socket_t's, apr_file_t's and many 
> other
> low level objects) between processes, and that would include passing an
> apr_spipe_t across processes without an apr_spipe_t already in 
> existence.

I know nothing of Windows, so I did not know that Win32 didn't provide a
fork type functionality.  It seems so basic that I just assumed it would
be there.  I apologize for my ignorance.

> To Justin's comment; no, there is no reason for a Unix Domain Socket
> object in apr.  If it doesn't [can't] extend portability with platform 
> specific
> implementation details, then it doesn't belong in apr.  E.g. apr has no
> reason to implement malloc and free, because malloc and free are
> already portable.  To the extent that we would create a wrapper around
> an already portable type, that is silliness.

PF vs AF is platform-specific, for example, as are some of the socket
options available for local sockets.  It's a standard type that generally
behaves a standard way, but the devil is in the details, and that's what
adding a local socket functionality (which I'm pretty sure is available 
on
some platforms !UNIX as well) would buy you -- the ability to wash hands
of the details.

And it's not strictly true that malloc and free are portable -- different
implementations do different things when malloc(0) and free(NULL) are
called, and there are different malloc implementations on the same 
platform
(malloc and mtmalloc on Solaris, for example).  And APR does sort of
implement its own malloc and free -- the whole pools concept is just an
abstracted version of malloc and free, and malloc could be used in any
situation where ap_palloc is used.

> The argument consistently advanced about an spipe style mechanism is
> that it would speak process-to-process on the same machine, only between
> spipes themselves.  We don't appear interested in implementing some
> specific mechanic that would be a communication link to non-apr 
> applications.

I'm not interested in that either -- if apr_spipe_t can support the same
sort of feature set that local sockets do, ie, the same sort of
create/listen + accept loop and multiple children doing connect with no
interleaving issues that a standard network socket can do, except not 
over
any sort of network, I'm more than happy to use it.  I think I can link 
in
the pieces of APR that the client application needs (as long as they're
fairly minimal) and still have the client application be small and sleek
and FAST.  Also, I might end up writing a version of the client
application as an Apache httpd module, in which case I'd have access to
the entire of APR with no extra overhead.

> Samba and many other projects offer platform specific and platform 
> neutral
> communications protocols.  Aaron proferred spipe to solve specific 
> problems
> between httpd processes that will have a terrific, useful impact on 
> win32
> implementations, without any regard to external communications.

I'm not arguing against spipe.  Without knowing what Aaron has planned 
for
it, I'm not even sure I can't use it in my application.

I'm also not sure how a communication protocol would help me -- I'm 
looking
for the medium, because I have the protocol already.

I'm just not sure I see why adding local sockets to the repertoire of 
socket types
apr_socket_t supports would be so horrible, rotten, or silly.  Sure, it's
not available on every platform, but again, neither is IPv6.  Neither is
IPv4, if you want to get really picky -- versions of VMS only had DECnet
unless you bought the IP stack addon, for example.  I understand that
there's not much demand for an httpd that runs on something that doesn't
have IP, but I was under the impression that you guys sort of wanted APR
to be picked up by other external applications to make it useful outside
of Apache httpd.  Some applications will want to allow users to use local
sockets instead of network sockets if that functionality is available for
their platform.  The X server, for example, as an extreme example.
xemacs' gnuserv/gnuclient.  Not that these would be re-implemented with
APR, but still, it's not an unusual requirement.

I hope I'm not horribly offending anyone on the list, but I think my 
request is
neither unreasonable nor unjustified -- and I'm more than willing to 
back it up
with a patch, if it would be accepted.

KH

--
Karsten Huneycutt               A casual stroll through a lunatic
kph@duke.edu                    asylum shows that faith does not
http://www.duke.edu/~kph        prove anything  --Nietzsche

[prev in list] [next in list] [prev in thread] [next in thread]