[altfredd]

Not really.

Binder solves a real-world problem — priority inversion. It is also the only IPC on Linux that allows to perform a blocking call from process A to process B (and have process B synchronously call back to process A if needed).

D-Bus, Varlink and other "IPC solutions" on top of sockets can not do those things. Android uses synchronous Binder calls for 90% of it's application APIs, so there is clearly a real use case for it.

Incidentally, Binder itself does not specify message format. A message is a simple memory buffer. Android runtime uses a custom binary serialization format, but you can use JSON or whatever. Binder is an alternative to sockets/pipes, not D-Bus or other wrappers on top of them.

[AshamedCaptain]

Binder was not even designed for Linux. The primary reason it is used is that (at the time) they wanted to abstract from Linux. "They" here is not Android/Google.

Binder also specifies a message format -- even if not fully, since the kernel is going to peek into your message for things like FDs, binder objects, etc. Or your userspace is going to need to "special treat" these fields somehow.

It competes in the same space as D-Bus no doubt. If the story of Android had been different, with the companies spinning off some years later, it may have very well ended up using Luna RPC (https://www.webosbrew.org/pages/luna-service-bus.html ) (which is practically indistinguishable from D-Bus, bar the JSON) or anything else, really.

> D-Bus, Varlink and other "IPC solutions" on top of sockets can not do those things.

WTF? Sure you can do on top of even pipes. Even XDR could...

"Synchronous" is a very loose word here if you mean to be interrupted in the middle of a RPC call, anyway.

[tadfisher]

Binder was invented at Be, Inc. for BeOS, and many Be refugees joined Android in the early days. (I just learned this recently on HN, so congratulations!)

[altfredd]

> WTF? Sure you can do on top of even pipes. Even XDR could...

Of course, you "can". Implement message-based communication on top of streaming. Emulate blocking calls on top of non-blocking socket API. Implement authentication via ancillary data (try not to throw up in process). Use some clever tricks to solve priority inversion. Somehow distinguish your fds from all others file descriptors to ensure that no confused deputy problems arise.

Congratulations! You have reached feature parity with Binder.

> Binder was not even designed for Linux.

Neither are Berkeley sockets.

[KerrAvon]

(You cannot actually fully solve priority inversion _and priority propagation_ on a fully async system. There are ultimately no tricks clever enough.)

[AshamedCaptain]

> Of course, you "can".

What is your point here? You claimed that "other IPC solutions" _could not_ do this on top of sockets, but as I've shown and now you admit, you definitely _can_. Obviously I'm not suggesting you roll this by hand, nor claiming that a plain UNIX pipe is a fully featured RPC system; just that there's a million RPC systems out there that do it and don't need anything else than sockets.

[gpderetta]

I don't know what binder does exactly, but rendez-vous synchronization is surprisingly hard to do efficiently on POSIX systems without excessive context switches.