> 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
--
You are receiving this because you are subscribed to this thread.
Reply to this
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
> > 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
> 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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
@cgwalters Nice! I’m working on Rust bindings to a small part of the RPM API.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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
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
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.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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
Closed #1483 via #1516.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1483#event-4249204767___
Rpm-maint mailing list
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.
11 matches
Mail list logo
