Messages in this thread | | | Date | Thu, 16 Apr 2015 00:27:16 +0100 | From | Al Viro <> | Subject | Re: [GIT PULL] kdbus for 4.1-rc1 |
| |
On Wed, Apr 15, 2015 at 03:54:10PM -0700, Andy Lutomirski wrote: > Huh, interesting. > > I was imagining that each of a server's peers (capability holders) > would have a fresh struct file, but maybe this wouldn't be needed at > all. You'd still need a way to get replies to your request, but the > API could just as easily be: > > int send_to_capability(int dest, int source, const void *data, size_t len, ...); > > where dest would be the destination's fd and source would be whatever > receive queue I expect the response on. > > So maybe this is feasible. It doesn't solve broadcasts, but dbus > unicast could easily layer over a facility like this and the context > switch problem would go away for unicast. > > Heck, I'd use it for my own proprietary stuff, too. It would be way > easier than the absurd tangle of socketpairs I currently use.
BTW, the main issue with AF_UNIX passing is that recepient isn't asleep awaiting for descriptors - they are thrown by sender at whoever's receiving and sit there until somebody gets around to picking them.
_IF_ we had client: I want a desciptor <goes to sleep, interruptibly> kernel: assign it a sequence number server: sees request (including sequence number) server: give this fd to originator of request #N kernel: check if originator is still there, insert the damn thing into their descriptor table if they still are and return the obtained number or server: tell the originator of request #N to fuck off kernel: check if originator is still there and gleefully pass the "fuck off" if they still are
we wouldn't have the in-flight state at all, and there goes the garbage collection shite. With some elaboration, it could even carry the authentication traffic - "fuck off" might be "answer this challenge", with the next "I want a descriptor" carrying reply...
| |