apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <ad...@rowe-clan.net>
Subject Re: More migration of code from httpd to apr-util
Date Mon, 11 Jun 2001 15:33:17 GMT
From: <rbb@covalent.net>
Sent: Monday, June 11, 2001 10:04 AM

> On Mon, 11 Jun 2001, Greg Stein wrote:
> > On Mon, Jun 11, 2001 at 12:38:23AM +0200, Luke Kenneth Casson Leighton wrote:
> > > On Sat, Jun 09, 2001 at 08:30:23AM -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.  Originally, APR supported named pipes on Windows, they were
> removed in revision 1.11.  From looking at the log, I don't understand
> why.

Ok.  Here are the not-so-subtle differences.

First, I understand 9x actually supports reading and writing to a named pipe
created on an NT/2000 machine, but they don't support them internally.  And they
are always blocking.

Second, the naming conventions are entirely different.  On win32, the name is
\\.\pipe\somepipename while on unix (if I understand it) any directory can 'host'
a named pipe.  On unix, my pipe can be apache2.0/connectors/foo, while on win32
it is all within that 'pipe' pseudofolder.  On Win32, we can actually open the
\\somemachine\pipe\somepipename from either 9x or WinNT, but the blocking features

All this implies a common support for 'flat' entries (no directory tree, or the
caviat that the 'path' will be ignored on win32.)  It implies one of; an alternate
file open call, a 'open pipe' flag bit, or returning the handles on open.

Which is also a requirement.  When we call namedpipe_create, we have to RETURN 
SOMETHING!  Win32 will create a pipe handle (not the same as the read/write file
handle.)  Every (NT/2000) machine could Create or Connect to get that pipe handle.
But once that pipe  handle is closed, the pipe evaporates, they are not persistant.

So some semantics change.  We don't 'rm' a pipe when we are finished with it, we just
close the last handle.  And pipes on win32 carry a 'suggested size', but the default
is a paultry 8kb.  

If this is what we want to use, let's start talking about what api we want.  I'm happy
to propose the changes to the _namedpipe_ functions that will get this working in the
next day or two on Win32.

> > > 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.

I really doubt it.  Time to start from scratch, for the reasons I cited above.

> > > - 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.

No, it effectively is a named pipe.  They *really* don't differ all that much.
The differences are in the naming rules, and Win9x compatibility.

Implementors are just going to have to accept that 9x aren't Operating Systems
in today's sense, but consumer appliances/gaming consoles, so they have 
significant drawbacks.  This does ***NOT*** imply I'm against getting httpd up
and running on Win9x!  It just means that the sort of advanced features that
cross-machine dce would implement can't be effectively targetted to Win9x, or
they must be coded around.


View raw message