> > > Funny you should bring that up (and particularly that ipc_ prefix). > > > Recently I've been working on a stream pipes proposal for APR that I have > > > yet to post. This is not quite the same as Unix Domain Sockets, so it > > > wouldn't be usable for things like EGD, but would be useful for perchild > > > portability. The main features are interprocess data communication and > > > the ability to pass apr_file_t and apr_socket_t types between processes. I > > > will post the API as soon as I have a working proof of concept on Unix. > > > > Hmm, well I'll wait to see it, but I actually think what we need is an > > implementation of ipc that is useful and flexible, not tied to simply > > passing sockets or file_t's between processes. > > my requirements are: > > - able to pass datagrams > - able to pass data efficiently, if possible (iovec prefered) > - able to pass files and sockets > > ... all between processes.
These all sound good and tie in with my ideas :) > > > > I'm thinking we can either work the Unix Domain Sockets and stream pipes > > > into one unified API, or if their attributes are too incompatible I see > > > no reason why we can't just have two sets of APIs. > > > > I don't think we should neccesarily follow too closely the Unix Domain model > > as it's just that, a Unix idea. Let's simply do what we've done before and > > come up with a suitable api. There have been a good few examples given of > > places where this could be useful. Any reason why you can't simply post > > what you've got so far? > > I agree, there is no reason to model the whole thing after UDSockets, > especially if they are completely non-portable outside of Unix. FWIW, > I am not implementing apr_spipe_t on top of Unix Domain Sockets. For the > sake of this discussion, I'll post my apr_spipe_t API shortly. Excellent :) david
