PATCH: get unix user speed up
misha at sun.com
Mon Oct 24 08:59:29 PDT 2005
On 21/10/05 15:58, Havoc Pennington wrote:
> On Tue, 2005-10-18 at 13:20 +0100, Michael Krivoruchko wrote:
>> I did not profile this, but this patch saves daemon almost 100% of time
>> on request of a connection uid.
> Of course, but is request of a connection uid any significant expense? I
> do see your point that it might be if we do per-uid names. btw, should
> the cache of uid be in BusConnection, why not in DBusConnection itself?
It is difficult to say how much of performance it would save on different
platforms, but it should save at least one round trip to the kernel land.
With frequent calls (say for each message) this might be noticeable saving.
I would prefer to cache uid in the daemon code as oppose to library just
because in peer-to-peer mode per-uid feature would not be used often if
at all. Anyway, this was my rational behind the chose.
>> Actually, I am working on per-uid message bus names. The idea is to let
>> a user to have private "channel" on the system wide bus. So the same
>> message bus name would represent different instances of a "service" for
>> different users.
> The potential complexity of this (especially when combined with security
> policies, guaranteed semantics of which signals you get, etc.) really
> melts my brain; I guess if you can show a solid well-unit-tested patch
> that doesn't add too much code, and justify the use case (see previous
> thread), we should be willing to consider it. But fair warning, my
> feeling up front is that it's going to melt my brain. ;-) Willing to be
> proven wrong, and if everyone thinks I'm crazy I'm not going to stand in
> the way. But I'm not convinced yet, let's put it that way. My experience
> is that people already find session vs. system bus confusing, and
> already can't figure out how to use the security aspects of system dbus.
For per-user daemon, you described at the bottom of the following message,
a well known name on the system bus would be right place, I believe.
> You have a daemon implementing the service, right? Why not just have it
> persist beyond login - you don't need a user bus to make your own daemon
> persist I wouldn't think. You can use the system bus (perhaps with some
> enhancements) to discover each new session and attach your persistent
> daemon to it.
The difference, however, is that there is no need to discover (watch for)
new user sessions. Instead, a new session would just use well known name
on the system bus in order to get access to per-user daemon.
More information about the dbus