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


Reply via email to