Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sdjournal: tie libsystemdFunctions to Journal's life #169

Closed
wants to merge 1 commit into from

Conversation

iaguis
Copy link
Contributor

@iaguis iaguis commented Jun 7, 2016

There was a map from function names to their addresses so we don't
need to call dlsym everytime we call a function from libsystemd if it
was already called before.

Every time we open a new Journal, we call dlopen() (and every time we
close it, we call dlclose()). Since the map was global and we weren't
clearing it up after closing Journal, we were reusing the addresses from
the previous invocation. This is wrong because libsystemd can end up in
a different address the second time we dlopen() it.

Store the map in the Journal struct so it's a per-Journal cache.

Should fix rkt/rkt#2740

There was a map from function names to their addresses so we don't
need to call dlsym everytime we call a function from libsystemd if it
was already called before.

Every time we open a new Journal, we call dlopen() (and every time we
close it, we call dlclose()). Since the map was global and we weren't
clearing it up after closing Journal, we were reusing the addresses from
the previous invocation. This is wrong because libsystemd can end up in
a different address the second time we dlopen() it.

Store the map in the Journal struct so it's a per-Journal cache.
@iaguis iaguis changed the title sdjournal: tie libsystemdFunctions to the Journal's life sdjournal: tie libsystemdFunctions to Journal's life Jun 7, 2016
@krnowak
Copy link

krnowak commented Jun 7, 2016

LGTM.

@alban
Copy link
Contributor

alban commented Jun 7, 2016

LGTM if Semaphore is green.

As said OOB, it's probably better to keep the library open rather than doing dlopen/dlclose at each method call. But this PR is a small patch that we can easily get in for the next release.

@iaguis
Copy link
Contributor Author

iaguis commented Jun 7, 2016

dlopen/dlclose at each method call

FWIW we only do it when the user creates a new Journal (and when she closes it).

@lucab
Copy link
Contributor

lucab commented Jun 7, 2016

I'm not sure this is a great approach: memory footprint will now be linear in the number of journal instances, and every instance will go through several misses every time (to populate symbols cache). Book-keeping overhead, in particular on short lived instances, seems considerable now. Can't we just dlopen it once and then let it go away on process exit, reusing the same symbols cache for all instances?

@iaguis
Copy link
Contributor Author

iaguis commented Jun 7, 2016

This PR implements the suggestion on #169 (comment): #170

@lucab
Copy link
Contributor

lucab commented Jun 7, 2016

Superseded by #170.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

api_service: GetLogs() panic when setting follow == true
4 participants