On Tue, Apr 21, 2015 at 9:51 PM, Bernd Petrovitsch <be...@petrovitsch.priv.at> wrote: > Hi all! > > On Die, 2015-04-21 at 09:37 -0400, Havoc Pennington wrote: > [...] >> This has long been sort of the 'party line' and I've told many people >> this on the dbus mailing list over the years (almost exactly what you >> just said - that for performance-critical cases they should open a >> direct socket or use something else or whatever). Usually this makes >> app developers a little cranky because something that was going to be >> easy in their mind just got harder. > > Perhaps these developers should rethink the design and protocols of > their apps - or pay the price for a stupid design which relies on heavy > IPC traffic (and usually - sooner or later - heavy network traffic). > Or - at least - deliver a (technical!) proof why this isn't feasible. > > The case of "patching the kernel to lie about the kernel's command line" > just because some ill-designed user-space daemon misused it" was bad > enough and the above smells quite similarly. >
I don't think it's ridiculous that app developers try the clean, simple solution first (use one IPC for everything) and only optimize once they discover they need to. If dbus were faster, many of these designs might not be stupid and might not be a mis-use. And the app might delete a lot of code, which is a plus for anyone using that app. More code = more bugs after all. I grant you that some apps have bad code, but I don't think it's my job to punish them by making things slow on purpose. I only made things slow because I didn't know a way to make them fast without sacrificing a more important goal, but it was never ideal. The kdbus developers have proposed a way out of the tradeoff. Havoc -- 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/
