On Mon, Jun 11, 2001 at 08:04:53AM -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.
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
