On Aug 6, 2015 1:04 AM, "David Herrmann" <dh.herrm...@gmail.com> wrote: > > Given that all existing prototype userspace that I'm aware of > > (systemd and its consumers) apparently opts in, I don't really care > > that the feature is opt-in. > > This is just plain wrong. Out of the dozens of dbus applications, you > found like 9 which are buggy? Two of them are already fixed, the > maintainers of the other ones notified. > I'd be interested where you got this notion that "all existing > prototype userspace [...] opts in". >
I would say instead that, out of one in-use kdbus library, I found one that was buggy. Maybe gdbus really does use kdbus already, but on very brief inspection it looked like it didn't at least on my test VM. > > > Also, you haven't addressed the memory usage issues -- > > ..because it doesn't change anything. If your IPC is message based and > async, _someone_ needs to buffer. I don't see the difference between > buffering locally on !EPOLLOUT or buffering in a shmem pool. In both > cases, clients have control over the buffer size. If you disagree, > please _elaborate_. If the client buffers on !EPOLLOUT and has a monster buffer, then that's the client's problem. If every single program has a monster buffer, then it's everyone's problem, and the size of the problem gets multiplied by the number of programs. Also, sensible clients that produce bulk data will throttle on !EPOLLOUT rather than blindly buffering, but that's not an option when the huge buffer is on the receiver's end. Read up on "bufferbloat". --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
