[Rpm-maint] [rpm-software-management/rpm] RFE: make rpm object ref counting atomic (#431)

The ref counting for rpm objects needs to become atomic to avoid Heisenbug's when attempting use of rpm objects in multithreaded environments. Yes the window doing increment/decrement is quite tiny, but is still not correct. There are of course other issues serializing RW access to object

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

There are almost no interesting usage cases for multiple transactions (at least until one attempts threaded installs, which are currently prevented by an exclusive fcntl lock in RPM4 anyways). What that means for bindings is that you can take out a static global transaction which can be used

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

Re a global rpmts There is rpmtsClean() to make the global rpmts reusable -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

Great! With that I can add a wrapper type for accessing it which acquires the lock, and when dropped calls `rpmtsClean()` as the last thing before it releases the lock. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

Actually, rpmtsInitIterator() is/was an attempt to simplify retrievals by hiding the DB handle getter within a pass through lookup. Acceptance and updating code has been glacially slow all century. Note that rpmdbOpen's calls have had some very peculiar side effects to accomodate user demands

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

> What I am suggesting (but I know nothing serious about rust) is running an > array of header references during an iteration using *Link() that have > *Free() called when the rust Iterator goes out of scope. Yep, that's exactly what I'd like to do. -- You are receiving this because you are

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

Re hiding header objects You an also hide headers in rust bindings. There are 3 places that headers become visible: 1) when read from packages in order to create a transaction This can be handled by passing *.rpm file names to rpmInstall or package names to rpmErase 2) Most usage cases for an

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

Re use of rust's regular Iterator type Since you are programming with rust+ffi there are some games you may be able to play with ref counting in C to adjust the lifetime of headers returned from an Iterator. What I am suggesting (but I know nothing serious about rust) is running an array of

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

> Do an additional ref++ using *Link() if you want to make a header persistent > for further processing outside of an iteration (but don't forget the ref-- > using *Free() or you will have a huge memory leak ;-) Are there any additional lifetimes to worry about here, e.g. the lifetime of the

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

Re using rust iterator S w ref counting The match iterator does a ref++ followed by a ref-- at the end of an iteration which guarantees that the header and MINMEM tag data exist for each iteration. Do an additional ref++ using *Link() if you want to make a header persistent for further

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

Re the RPM5 doco That do yen info hasn't been updated for almost a decade (but not much has changed since last century). (aside) Meanwhile there are some significant differences in RPM5 match iterator S, including lazy index generation, partial matches on patterns applied to Bree index keys

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

Aha, so if I call this: http://rpm5.org/docs/api/group__header.html#g4f07e8040ed3195e374a44919ffe97c2 ...and `headerFree()` on drop, it sounds like I could switch to a normal Rust iterator which iterates over immutable references. -- You are receiving this because you are subscribed to this

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

Re: ref counting. Yes, an increment is exactly a *Link() call, and a decrement (and possible delayed/lazy de-allocation) is a * Free() call. There is also a *Unlink() method that is strictly a decrement w/o a deallocation, but that is really only useful when debugging, or when some snarly ref

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

(random comments on db.rs retrievals) Note that mire (match iterator regular expressions) can be rather expensive if patterns are used. rpm itself almost always uses strings through an index for performance. A proper implementation for mire patterns would need to do a partial match on the

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

@n3npq a few questions about something you said earlier: > RPM object (like ts, h, db) is ref-counted, but the counter increment is not > atomic. When are the reference counts incremented/decremented, and can I bump them externally? If so, I could have Rust increment the reference count when

[Rpm-maint] [rpm-software-management/rpm] RFE: make rpm object ref counting atomic (#430)

The ref counting for rpm objects needs to become atomic to avoid Heisenbug's when attempting use of rpm objects in multithreaded environments. Yes the window doing increment/decrement is quite tiny, but is still not correct. There are of course other issues serializing RW access to object

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

@n3npq yeah I've been meaning to add some sort of higher level facade around `Header` which makes it easy to do the obvious things like get the package's name and description, but I wasn't quite sure what it would look like yet. @Conan-Kudo thanks! -- You are receiving this because you are

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

@tarcieri The rpm.org/rpm4 documentation can be found here: http://ftp.rpm.org/api/4.14.0/ -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

IMO it makes sense to use `rpm` + `rpm-sys` as a crate names. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

[Rpm-maint] [PATCH] Add API to add arbitrary tags to headers saved to rpmdb

--- lib/depends.c| 23 +-- lib/rpmte.c | 28 +--- lib/rpmte_internal.h | 3 ++- lib/rpmts.h | 30 ++ lib/verify.c | 2 +- 5 files changed, 75 insertions(+), 11 deletions(-) diff --git

Re: [Rpm-maint] [PATCH] Add API to add arbitrary tags to headers saved to rpmdb

> On Apr 13, 2018, at 3:49 AM, Aleksei Nikiforov > wrote: > > --- > lib/depends.c| 23 +-- > lib/rpmte.c | 28 +--- > lib/rpmte_internal.h | 3 ++- > lib/rpmts.h | 30 ++ >

Re: [Rpm-maint] [rpm-software-management/rpm] Rust bindings for rpmlib (#429)

I would have used `rpm`, unfortunately someone else took it for something completely unrelated (and won't give it up, I already asked): https://crates.io/crates/rpm -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: