[systemd-devel] [PATCH 0/2] RFC for avoid dynamic allocation in?journald

[Lennart Poettering]

On Mon, 08.04.13 14:02, Holger Freyther (holger at 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.