httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: More migration of code from httpd to apr-util
Date Mon, 11 Jun 2001 15:12:44 GMT
On Mon, Jun 11, 2001 at 08:04:53AM -0700, rbb@covalent.net wrote:

> > > > BTW, APR already has named pipes.  Just what are we trying to solve here?
> >
> > We only have them implemented for Unix. OS/2 returns an ENOTIMPL and Windows
> > simply doesn't have an implementation for it.
> 
> So, the solution is to implement them on other platforms, not to re-invent
> them.  For historical completeness however, allow me to explain how we got
> where we are with named pipes.  Unix has them becaues they are easy to
> implement.  Windows doesn't have them because only certain versions of
> Windows supports named pipes.  Namely, NT and 2000 have named pipes, 9x
> doesn't.  

grep NamedPipes */*.c shows some code that uses NPs.
there is a nice comment about 9x not having some
feature [blocking or something], and it says, well,
uhhh.... TOUGH! :)

so, there does already exist code in apr that uses
CreateNamedPipe() - for different purposes.

> Originally, APR supported named pipes on Windows, 

great!!!

> they were
> removed in revision 1.11.  From looking at the log, I don't understand
> why.
 
*curious*.

> > > i looked at the named pipe code: i believe that you are thinking
> > > of 'unix' named pipes, which are a totally diffrerent beast
> > > from nt named pipes.
> >
> > Right. I don't recall all the bits about creating named pipes in Windows,
> > but it may be feasible to use the "filename" in the
> > apr_file_namedpipe_create function for the host/name of the pipe in NT. In
> > other words, it may be a simple matter of writing the function for Windows.
> > But then again, the function params may not be rich enough for what is
> > needed.
> 
> See above, this has worked in the past, all we need to do is copy the code
> back into place, and possibly tweak it.

yesplease!  less work!

> > >...
> > > - a means to set up a server and have other programs (not
> > > remote programs) connect to and communicate with that server.
> > >
> > > the semantics must be identical to those of unix-domain-sockets,
> > > namely a listen, bind, accept, read, write and close.
> >
> > I would think you could use named pipes, TCP sockets, or Unix sockets.
> >
> > If the server spawns the programs, then you can also use regular pipes.
> 
> I have been thinking of creating apr/rpc/...   to handle stuff like this.
> However, right now, we have named pipes.  They need to be implemented on
> more platforms, and that may require changing the API a bit, but please
> let's stick with what we have already.
> 
> The only thing we can't do with named pipes today is communicate with
> different machines.  IMHO, calling any cross-machine communication medium
> a named pipe is just going to confuse any unix programmer.  Give it a
> different name.

okay.

i am familiar with how remote IPC works, from a few perspectives,
having implemented a subset of DCE/RPC that is MS-compatible,
over SMB, for Samba (ISBN 1578701503).

[eek, have bus to catch soon, gotta run].

i can attest to the complexity of implementing such: it's
not something to add to a simple library like APR without
a *lot* of prior thought - an implementation may be about
7,000 to 10,000 LOC - not trivial.

gotta run, more later.

all best,

luke

Mime
View raw message