On Mon, 08.04.13 14:02, Holger Freyther (hol...@freyther.de) wrote: > Just adding the path to the dispatch_message_real signature is a bit > tricky as the server_driver_message is creating a ucred with the pid, > gid,uid of the journald process... > > Is it really needed to determine the cgroup of /proc/1 on every message? > Couldn't journald keep the variables for its identity around?
Sounds like something we could certainly cache. However, remember that much of the code in question *might* already be used by PID 1 itself before it migrated to its own cgroup subtree, so we should make sure to handle this properly, so that no out-dated data is cached. i.e. the least we'd need to do is document (in a comment) that these calls may not be called during PID1's early initialization and verify that it currently isn't. The other question would be were to stored the cached data: We are a bit conservative with static vars in 'library' code such as util.c or cgroup-util.c, since we want things like that to just work in threaded environments, too. (Note that code like util.c/cgroup-util.c is used by code exported in libsystemd-login, libsystemd-journal, libsystemd-bus and so on, even though the API of util.c itself is not exposed) However, for a few things where this ended up being worthwile we do have static cache vars, and there are two ways to make them MT safe: a) use gcc's __thread support, i.e. have one static cache var per thread. Since all stuff in systemd's repo is essentially single threaded this should give you the desired effect and should be a pretty simple way to have caches without having to think about concurrency. Of course, this only really works for small fixed-size data that needs no destructors (i.e. no free()). b) Only provide the caching in the main thread, and be un-cached expensive in all others. This is slightly less nice, but effectively gives you the same properties for systemd's own code. We have a call in util.c to detect if we are running in the main thread: is_main_thread(). Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
