Replace internal maps with unsorted Vecs

[hanna-kruppe]

HashMap and BTreeMap are overkill in this context. Unsorted vectors are plenty fast enough and the necessary collection interfaces are straightforward to implement. This change has two benefits.

First, it improves binary size. For the print example from signal-hook in release mode, the .text section shrinks by about 18 KiB and overall file size shrinks by about 30 KiB. That's roughly a 6% reduction in both metrics.

Second, the simpler data structures make it more obvious that the signal handler only does async-signal-safe operations. In particular, the default HashMap has a RandomState, which can access TLS, do dlsym lookups, open and read from files, etc. depending on the platform. I don't think that's a problem for the hash table lookup done in the signal handler since that shouldn't touch the RandomState, but it's a bit subtle and the standard library doesn't make any guarantees about this. Avoiding hash maps entirely removes the need to think about it.

Performance notes:

• (Un-)registering actions does an insert/remove by ActionId, which is asymptotically slower with this PR. However, (un-)registering is a slow operation and should be done rarely. Besides locking, it always clones the entire SignalData, so it already takes O(n) time when there's n actions registered across all symbols.
• The signal handler looks up the Slot by signal number, which is asymptotically slower with this PR. However, there's only a very small constant number of signals, so asymptotics don't matter.
• After looking up the right Slot, the signal handler only iterates sequentially over the actions, it doesn't do any lookups by ActionId.
• For a simple microbenchmark that registers one action each for 20 signals and then raises one signal 100k times, this implementation appears to be slightly faster regardless of which signal is raised.

[hanna-kruppe]

Note: despite the claimed advantages, I would 100% understand if this was rejected to avoid having to review and maintain the hand-rolled map implementation. But I was curious how much it help w.r.t. binary size, and once I had implemented it, I figured I might as well write a proper commit message and submit a PR in case it's of interest.

[vorner]

Looking at it, it looks in a beneficial direction. Though I'd still have few suggestions, if I may:

• Do we need a full container-like API or are some of the methods unnecessary? The Entry API seems a bit heavy here (I know it's used, but maybe we can get away without?), I'm not sure if get_mut is necessary.
• It would make sense to have at least few tests for the container.
• I wonder if it would make sense to keep the keys sorted and use binary search for lookup.

[hanna-kruppe]

Do we need a full container-like API or are some of the methods unnecessary? The Entry API seems a bit heavy here (I know it's used, but maybe we can get away without?), I'm not sure if get_mut is necessary.

I started out by modifying the places using collection APIs to open-code Vec wrangling, which turned into a big mess halfway though. It's quite possible that I over-corrected in the other direction! I'll take another look at the uses of Entry and get_mut.

I can add some basic tests once the API surface is settled.

I wonder if it would make sense to keep the keys sorted and use binary search for lookup.

That was actually my first instinct, but my initial attempt at it became too hairy halfway through (not only due to open-coding). Then I took a step back and came to the conclusion that it's an unnecessary complication for no performance gain (see analysis in the commit message). But maybe the scales tip the other way if the API surface is trimmed down. On the other hand, if the entry API goes away, there's less need for the index-based find helper function to work around borrow checker limitations... I'll think about it again.

[hanna-kruppe]

Updates:

• Rebased on Various CI fixes #193 for now (got annoyed by clippy warnings while developing) and fixed a stray BTreeMap mention in cfg(windows) code that CI caught
• Got rid of the entry API, was only used in one place and the borrowck-friendly "check if key is present, get_mut().unwrap() if yes" dance is not too bad there.
• I tried the "sorted Vec" approach in the last commit. With separate vectors for keys and values, it's tolerable because <[T]>::binary_search works as-is. But it doesn't seem clearly better either, and technically the invariants are more involved. What do you think?

[vorner]

When I'm looking at it, I'd say the sorted version adds a lot of complexity to the code that's probably not worth it.

So, my proposal: can you rebase (the CI was merged to master), remove the last commit and add some tests, so we can merge it?

[hanna-kruppe]

Done.

[hanna-kruppe]

A CI job appears to be stuck in a signal-hook-async-std doctest: https://github.com/vorner/signal-hook/actions/runs/19989264522/job/57327601452?pr=192#step:5:453

I can reproduce this locally by running while true; do cargo test --doc -p signal-hook-async-std; done. It reproduces outside of this branch (e.g., on ac4c81c) so I guess it's a pre-existing race condition of some sort?

[hanna-kruppe]

(Pushed a no-op git commit --amend to hopefully get CI un-stuck.)