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
