CK.OpenSession(): Do not block on run-seat.d scripts?

CK.OpenSession(): Do not block on run-seat.d scripts?

[Martin Pitt]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

Hello William,

I am currently investigating boot speed improvements, and one
particular item is that gdm hangs half a second in
ConsoleKit.OpenSession(). The reason is that it synchronously calls
all run-seat.d/* scripts, which includes udev-acl.ck.

I'm working on speeding up udev-acl.ck, but I need to discuss that
with Kay Sievers first.

However, I wondered why it is synchronous in the first place: The
hooks are called with a couple of environment variables, but CK does
not read any kind of result from them. In other words, the scripts
can't influence session properties, nor abort the creation of a
session.

Is there a particular reason for CK to wait on all the hooks? If not,
I'm happy to work on a patch to call those in the background. The only
thing to watch out for, as far as I can see, is that a call to the
hooks must not overlap with the next seat change, so this requires
some locking.

Thank you, and Merry Christmas,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: CK.OpenSession(): Do not block on run-seat.d scripts?

[Lennart Poettering]

On Mon, 21.12.09 15:17, Martin Pitt (martin.pitt@ubuntu.com) wrote:

Heya,

> I'm working on speeding up udev-acl.ck, but I need to discuss that
> with Kay Sievers first.
> 
> However, I wondered why it is synchronous in the first place: The
> hooks are called with a couple of environment variables, but CK does
> not read any kind of result from them. In other words, the scripts
> can't influence session properties, nor abort the creation of a
> session.
> 
> Is there a particular reason for CK to wait on all the hooks? If not,
> I'm happy to work on a patch to call those in the background. The only
> thing to watch out for, as far as I can see, is that a call to the
> hooks must not overlap with the next seat change, so this requires
> some locking.

We'd be very ill advised if (again) we'd do stuff like ACL fixes
asynchronously in parallel to sending out the CK session messages. You
really dont want that, because then clients which listen for session
change messages could not rely on the ACLs being set up correctly when
they get the message.

The dbus messages really need to be the last thing that happens, the
seat.d hooks *must* be finished first, unless you are a sucker for
raciness nightmares.

In HAL this used to be different (i.e. asynchronous), and among other
reasons that's why HAL was broken.

Also note that /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck is actually
*not* a script. I cannot really believe that there is really that much
to optimize here in this area... Except maybe that udev-acl might not
be particularly fast since it iterates through the device list
linearly?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4