My knowledge is outdated, as I last seriously looked at it about nine years ago, but I doubt Binder is even better than dbus; it was not good. I'm quite surprised with people suggesting it. There was that recent kernel Binder bug even with the rust implementation. It was rewritten in rust because it has had a never-ending string of serious security bugs. On top of that, it had very poor throughput. I'm guessing this improved with the rust implementation.
It was a toy created by former OS devs who really didn't want to use Linux, but wanted their pet IPC from their former OS. It even used to be the case that Binder would dynamically create threads in the receiving process without userspace knowing. As in, your process would magically have function calls coming in from threads that you never created. Imagine the issues this can create with locking, forking, etc. This ended up being changed to get it upstreamed, but I consider this absolutely insane behavior.
1. Better devex. The toolchain for binder properly checks that you are writing and reading transactions correctly and if you don't you get a compile time error. Meanwhile using dbus you can call things wrong and it will still compile.
2. Better latency. When you send a Binder transaction to another process Linux will immediately schedule the binder thread of the other process, unless it's a oneway transaction that does not block executon. Then once the other process replies, the original process is immediately rescheduled. Dbus does not affect Linux's scheduling of processes. When you send a dbus message any other process can be scheduled and run instead of the bus. And then anything can run in-between the bus sending the message to the target process.
3. Having the message go through the bus also results in extra copying. Not just cheap copying of memory. Since it's through a UNIX socket it has to use extra system calls to read out of and into another socket. As opposed to binder where it's able to simply copy the memory of the parcel from one process to another.
My knowledge is outdated, as I last seriously looked at it about nine years ago, but I doubt Binder is even better than dbus; it was not good. I'm quite surprised with people suggesting it. There was that recent kernel Binder bug even with the rust implementation. It was rewritten in rust because it has had a never-ending string of serious security bugs. On top of that, it had very poor throughput. I'm guessing this improved with the rust implementation.
It was a toy created by former OS devs who really didn't want to use Linux, but wanted their pet IPC from their former OS. It even used to be the case that Binder would dynamically create threads in the receiving process without userspace knowing. As in, your process would magically have function calls coming in from threads that you never created. Imagine the issues this can create with locking, forking, etc. This ended up being changed to get it upstreamed, but I consider this absolutely insane behavior.
1. Better devex. The toolchain for binder properly checks that you are writing and reading transactions correctly and if you don't you get a compile time error. Meanwhile using dbus you can call things wrong and it will still compile.
2. Better latency. When you send a Binder transaction to another process Linux will immediately schedule the binder thread of the other process, unless it's a oneway transaction that does not block executon. Then once the other process replies, the original process is immediately rescheduled. Dbus does not affect Linux's scheduling of processes. When you send a dbus message any other process can be scheduled and run instead of the bus. And then anything can run in-between the bus sending the message to the target process.
3. Having the message go through the bus also results in extra copying. Not just cheap copying of memory. Since it's through a UNIX socket it has to use extra system calls to read out of and into another socket. As opposed to binder where it's able to simply copy the memory of the parcel from one process to another.