Document thread-safety of librpm

[DemiMarie]

I have not been able to determine if librpm is thread-safe. From looking at the code, it appears not to be, for several reasons:

• librpm changes global state, such as the process umask.
• Lua scripts can change the environment, which can race with access to the environment from other threads. They can also change the working directory, which would be a problem in multithreaded use.
• Lua code can call fork() and allocate memory before calling exec(). In a multithreaded process, this is undefined behavior according to POSIX.
• librpm calls plugin hooks after forking. There is no guarantee that these hooks only use async-signal-safe interfaces.

This is merely a request for documentation of the status quo. The best way to use librpm in a multithreaded process is most likely to spawn the rpm binary. Parts of librpm, such as signature verification, are probably thread-safe, but running transactions probably isn’t.

[DemiMarie]

Are there problems due to concurrent calls to chdir() or calls to setenv by Lua scripts? Also, Lua scripts can call fork(), allocate memory, and then exec(), which POSIX only allows in a single-threaded process.

To me, it seems safer to only invoke the RPM transaction APIs when only one thread is running. @pmatilai thoughts?

[pmatilai]

Well yes, most people will find the going along a running transaction a bit too much when not just the current directory but also the root can change and whatnot.

[DemiMarie]

The reason I am asking is that I am working on (not yet published) Rust bindings to a small part of the RPM API. Rust requires that safe code not be able to invoke undefined behavior. Is it safe to fork() and then perform an RPM transaction in the child process, even if the parent was multithreaded?

[cgwalters]

FWIW in rpm-ostree we reimplement most of the RPM install path for multiple reasons (among them we "snapshot" multiple RPM versions into ostree commits as part of implementing transactional updates, we want to sandbox scripts etc.) but another big reason is that we simply cannot have librpm call chroot() - that has process-global effects and rpm-ostree is multi-threaded (like nearly all nontrivial software).

(Also on this topic btw rpm-ostree is oxidizing fast now, see e.g. coreos/rpm-ostree#2502 which I just submitted - so if there's RPM+Rust topics it might come up there too)

[DemiMarie]

@cgwalters Nice! I’m working on Rust bindings to a small part of the RPM API.

[pmatilai]

Is it safe to fork() and then perform an RPM transaction in the child process, even if the parent was multithreaded?

It depends on so many factors I can't possibly answer such a question.

[DemiMarie]

Is it safe to fork() and then perform an RPM transaction in the child process, even if the parent was multithreaded?

It depends on so many factors I can't possibly answer such a question.

Does librpm use pthread_atfork to protect its locks, and do the libraries librpm depends on do so?

[DemiMarie]

RPM depends on SQLite which cannot safely used in a child process after fork. So the answer is “no”, meaning that the only reasonable approach is to perform an RPM transaction using a separate binary.

[Conan-Kudo]

Nice! I’m working on Rust bindings to a small part of the RPM API.

@DemiMarie Note that there are already RPM Rust bindings that you can contribute to: https://github.com/rpm-software-management/librpm.rs