From: <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] 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 change. 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. Bill
