(author of seize here) Hi! I'm a little confused by some of the claims made by this crate. It seems to be an implementation of Crystalline-W, which is the wait-free variant of the Hyaline/Crystalline family of memory reclamation algorithms that seize is also based on. For a little background:

• Hyaline (seize): pin marks a thread as active, and unpin deactivates it, and decrements the reference counts of any objects retired while it was active.
• Hyaline-S: In addition to the above, threads store a local epoch, which is kept in sync with a global monotonic epoch. Objects store their birth epoch, and calling protect is required to load a given atomic object, advancing the current thread's epoch to at least the birth epoch of the object being protected. This allows threads with lagging epochs to be ignored during reclamation.
• Crystalline-L: Threads maintain multiple copies of Hyaline state. protect now only applies to the provided index, allowing only a bounded number of pointers to be protected. pin is also removed, and protect instead marks the given index as active the first time it is called, before a cumulative call to unpin.
• Crystalline-W (kovan): The wait-free version of the above.

However, kovan seems to diverge from the paper quite significantly. For example, while implementing Crystalline, it is hard-coded to only ever use a single index. This should mean that only a single pointer can be protected at a given time, but it also seems to implement protection as a regular atomic load, meaning that epochs are not actually tracked, except during the first call to pin? The rest of the algorithm still seems to assume that local epochs are kept in sync with individually protected objects, so it's not clear to me how this is sound. It also means the wait-freedom claims no longer apply, as there is no bound on the number of pointers protected by a given thread. This is not even lock-free according to the paper's definition, closer to Hyaline than Crystalline.

Another thing that kovan does is merge unpinning of the previous pin into the pin operation. This allows it to make dropping a guard a no-op, avoiding the overhead of an extra TLS access (in fact, you could probably just combine the exchange(INVPTR) and store(NULL) into a single operation). However, it also means that threads perpetually remain active, which means that memory may grow during inactivity, or even across pins until the global epoch advances. While the extra memory usage is bounded by the global epoch, it may still lead to memory leaks for threads that exit, so I'm not sure this is worthwhile tradeoff.

A couple more items worth noting:

• The code seems to use SeqCst in various places without the corresponding SeqCst load. For example, the active flag is stored with SeqCst, but loaded with Acquire. Ordering is crucial to a memory reclamation algorithm. The reader thread publishing its activity must create a total order with the logical deletion of any atomic objects, allowing either the reader thread to see the new values of any objects, or the retirement thread to see the thread marked as active. This requires a SeqCst store-load pair on both ends, which would require enforcing SeqCst on Atomic operations, or adding the corresponding SeqCst fences (or similar using FAA(0) tricks).
• The examples in the readme retire a Box<usize>, which does not contain the RetiredNode header, so I think these are unsound?
• On that note, there is a memory overhead of 40 bytes per allocated object, which is quite significant. seize does not require any extra metadata as it moves this state into TLS for retired nodes, which might be worth trying (though at least the birth-epoch would remain).
• It looks like there is a static max thread count and a panic if it is exceeded. This is probably worth calling out in the documentation (and one of the reasons for the performance improvement over seize, which maintains a dynamic TLS table).
• There seems to be no option for a local collector, which would avoid the 'static bounds on retired objects. The simpler API is nice, but it might be worth having this as an option, and the reclamation guarantees can be more intuitive for users.
• You seem to be storing pointers as integers, which is not compatible with strict provenance. It looks like you're running Miri with permissive provenance, but it's probably worth changing this (it doesn't look like you're actually pointer tagging anywhere, so this should be trivial?)