From: "Sander Striker" <[EMAIL PROTECTED]> Sent: Friday, January 11, 2002 6:29 AM
> > From: David Reid [mailto:[EMAIL PROTECTED] > > Sent: 11 January 2002 13:21 > > > > > David Reid wrote: > >>> If this is the case then why are we having this discussion about adding > >>> more to the network_io and not simply talking about adding an ipc_ set of > >>> functions to apr that allow each platform to implement it in their own > >>> way, as we've done with all the other stuff in apr? After all that's what > >>> apr is for isn't it? :) > >> > >> That is only a small addition to the apr sockets. > > > > But that's NOT really the point is it? The point is that not all the > > platforms can truly support this functionality and adding it just so we have > > it on some platforms and everyone else has to return ENOTIMPL seems to be > > crazy and against the very reason for APR. > > I agree. We need a portable ipc mechanism. > > >> An ipc_ should be in apr-util? That is a higher level layer. > > > > OK, so apr-util, I could care less where it goes, it's more the concept that > > I'm concerned about. > > It belongs in APR, because otherwise you have to do runtime checks in apr-util > to see if APR_ENOTIMPL is returned for unix domain sockets and then try the > thing we have as a fallback for a different platform (yuck). Agreed, this is an apr feature. If we have higher level constructs to stuff info into or out of an apr_ipc_ entity, those could live in apr_util (much like rmm does. In fact, rmm would already work for some sorts of marshaling, but it's isn't ideal.) There are two features that we can't neglect, however, while designing this. They can be supported on nearly any platform, but the devil is in details. The first is passing fd's from one process to another. fd's, that is, that weren't created by a common ancestor. This requires streams, domain sockets or win32 DuplicateSocket tricks. The second is passing auth entities from one process to another. Same deal. But for Win32, please keep in mind we actually have to conduct a round-trip conversation. In Unix, you simply pass the fd on through. On win32, the sender needs a handle to the recipient process (or it's process id.) So details do vary a bit. I'd like to keep this light. I'll posit my httpd idea for a parent-child process conversation queue in just a bit. But that's much heavier (I think) than what our apr_ipc_ users require. Bill
