From: <[EMAIL PROTECTED]> Sent: Monday, June 11, 2001 10:58 AM
> > 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. > > Not to be contrary, but can't we handle this by registering a cleanup with > the handle? That way, the handle survives until we specifically clean it > up, and we shouldn't have to change the API much. Not saying this is the > right way to go, I am just offering suggestions. No, I don't think it's the right way. I'd expect that we add a placeholder of apr_namedpipe_t that contains the name of the pipe on Unix (and nothing more), or the pipe name and handle on Win32. Opaque, of course. > > > 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. > > My problem with calling this a named pipe, is that Unix named pipes can't > do cross-machine communication. I think that if we call these things > named pipes, then in people's (Unix programmer's) minds, there weill be > limits that don't actually exist. Yes, they can learn what we mean by > named pipes, but why make it harder than it needs to be? Pointing out that they 'can' communicate between machines does _NOT_ mean we would actually implement that feature :-) I'd suggest we plunge forward, with a return type that lets us kill the pipe later (on Unix, that's nothing more than an rm namedpipe->name, no? on Win32, closing the handle) and register a cleanup on it, of course! Bill