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 [EMAIL PROTECTED] asylum shows that faith does not http://www.duke.edu/~kph prove anything --Nietzsche
