On Sat, Mar 22, 2014 at 3:43 PM, Daniel Mack <[email protected]> wrote: > On 03/21/2014 12:35 PM, Djalal Harouni wrote: >> I've two questions: >> >> 1) Can we improve it in ordre to reduce the lock hold time ? > > We don't consider that a very frequent operation, so we never thought > about optimizing this code path. What use case do you have in mind so > that performance would matter much? > >> currently creating a domain will make create/disconnect/open... buses >> and endpoints on the parent of that domain block, these are separated >> operations on different domains. > > I don't quite follow. Can you elaborate?
Creating domains and buses are relatively expensive system operations, they involve udev, device node creation, sysfs/driver-core interaction. If you think it's worth, please try it, we just took the easy road so far, not sure how much we can really optimize here. >> Also it seems that now there is only support for one level of nested >> domains? will this be increased? > > I don't think so. What's your use case here? We never tried, but the code was supposed to allow stacking of them. I'll fix it. >> 2) What about creating custom endpoints on the bus that was already >> unrefed ? IMHO this is the same scenario! > > That shouldn't happen of course. We've been dealing with locking in that > area quite a bit, but we might have overlooked something. Please send a > patch if you see such an unsafe locking scenario. > >> Hmm perhaps this can be improved by taking a ref ASAP and revalidate >> objects by checking the "*->disconnected" ? > > ->disconnected isn't so much of an issue, and we do check for it where > necessary. Apart from that, users that store a pointer to any object > should take a reference, so it can't disappear underneath them. But > again, if you think we've overlooked anything, let us know. Reviewing > all these details is certainly much appreciated. I'll add a few more "disconnected checks" before we link into the parent objects. Kay _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
