On Mon, 21.12.09 15:17, Martin Pitt (martin.pitt@xxxxxxxxxx) 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 -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
