| |||||||||||||
Missing the AF_BUSMissing the AF_BUSPosted Jul 6, 2012 6:24 UTC (Fri) by smurf (subscriber, #17840)In reply to: Missing the AF_BUS by iabervon Parent article: Missing the AF_BUS
socketpair-ing the sender and recipient would probably work, but it has a few downsides.
* you lose the easy debugging and monitoring you now get with DBus (presumably, with AF_BUS you could use something like wireshark),
* the client now has to juggle multiple file descriptors, that requires an API change
* multiple file descriptors and reliable message ordering don't mix
Too many downsides if you ask me.
(Log in to post comments)
Missing the AF_BUS Posted Jul 6, 2012 6:58 UTC (Fri) by Fowl (subscriber, #65667) [Link]
Surely libdbus could handle this all automatically?
Missing the AF_BUS Posted Jul 6, 2012 16:18 UTC (Fri) by smurf (subscriber, #17840) [Link]
The multiple-file-descriptors problem is the killer,
dbus_connection_get_unix_fd() returns exactly one file descriptor. If you open a direct connection to some application, you have more than one file descriptor. How do you make your application select()/poll() on both (or more) of these?
How would you propose to handle the monitoring problem? Let the daemon send a "somebody's listening for messages X, so if you exchange any of those privately, kindly send me a copy" commands to each and every client? Owch.
I'm not saying this cannot be done. I'm saying it's heaps more work, and more fragile, than simply moving the main chunk of this into the kernel, especially since there's already code which does that. And code is more authoritative than English.
Missing the AF_BUS Posted Jul 6, 2012 17:32 UTC (Fri) by iabervon (subscriber, #722) [Link]
I think I was unclear: I'm not suggesting that DBus do some sort of socketpair thing to provide high-speed dbus links; I'm suggesting that use cases that don't really care about DBus, but need to negotiate with another program for their input, could get back to their normal operation (input from a fd) by having the other side send a fd back when it's all set up. That is, user input doesn't normally go over DBus, so applications are already designed around a non-DBus input path; even if you need IPC to set up your input device appropriately, it doesn't make too much sense to get user input over DBus, particularly if you can't get corresponding user input over DBus if the system doesn't have Chinese input or multi-touch.
Of course, it's certainly possible that people will want high-speed IPC with DBus properties also, and it makes sense for DBus to be efficient regardless of whether it's running into performance constraints. But it doesn't make sense to use DBus for all communication, even if its performance could be made good enough.
|
|||||||||||||