mirrors/arti.git/crates/tor-memquota/src/mtracker, branch arti-v1.2.8 mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.2.8 2024-09-25T14:37:18Z Upgrade to derive_more version 1.0.0 2024-09-25T14:37:18Z Nick Mathewson nickm@torproject.org 2024-09-25T14:37:18Z urn:sha1:6a12c2ba8515226a772d5f4a81930bf42d67535a The `derive_more` crate broke backward compatibility with this version, so this change involved quite a few manual fixups. With luck, they'll keep compatibility for some while in the future. tor-memquota: Use clippy::arithmetic_side_effects, against panics 2024-09-10T12:06:35Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-10T11:43:29Z urn:sha1:d2e4f58f2a57c04b4a821b3850b31cc3e00c4a46 This detect possibly-panicking operations. Empirically this lint seems rather better now. tor-memquota: Avoid a perhaps-impossible division-by-zero (fmt) 2024-09-10T11:42:37Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-10T11:42:28Z urn:sha1:522186db935a3126a304742b96ec3196e5abe9b3 tor-memquota: Avoid a perhaps-impossible division-by-zero 2024-09-10T11:42:37Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-09-10T11:37:35Z urn:sha1:382157c735f1117ea0122031b3b04d352cda99af It is not locally obvious that n_particips can't be zero, here. Certainly if it *is* that would be state corruption, but I don't think I can quite rule it out in the presence of a bug somewhere else. tor-memquota: Break out reclamation wakeup 2024-09-04T12:26:47Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-08-28T15:43:43Z urn:sha1:e099d2414209f5df2431cc3d161ec7e81ae6cc23 tor-memquota: Make reclamation wakeup no longer throw internal errors 2024-09-04T12:26:47Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-08-28T15:37:36Z urn:sha1:0c823ec5061916c76516488811043917fc06d8f5 I realised a way this could happen without there being a bug. tor-memquota: Rework optionality configuration 2024-09-04T10:47:56Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-08-27T13:19:49Z urn:sha1:12f233e9c0f301a247edb44df67f1c60027d765e Allow a `Config` to represent "this is supposed to be disabled". This involves wrapping the actual built configuration in an IfEnabled. We treat max = usize::MAX, or max being unspecified, as "disable". We can now reporting an error during config building if max is set but we're compiling the feature out. Conversely, we can now make `MemoryQuotaTracker::new()` unconditional, since enabled confiogurations are uninhabited when the feature is compiled out. We change how we derive the setters, deriving them from the Builder. I chose to abolish the use of derive_builder. See the new comment on ConfigBuilder. Fix typos 2024-09-03T08:09:02Z Dimitris Apostolou dimitris.apostolou@icloud.com 2024-09-03T08:09:02Z urn:sha1:676f913463b7d84f34dd6101b99d03ef79cf57ad byte_qty: Move to tor-basic-utils 2024-08-27T11:46:06Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-08-22T12:24:59Z urn:sha1:dcb8d005f978d92b27be7887d6d24de23e0a2804 Code motion of byte_qty.rs, and minimal necessary supporting changes. tor-memquota: Pass EnabledToken to IsParticipant methods 2024-08-19T17:10:29Z Ian Jackson ijackson@chiark.greenend.org.uk 2024-08-19T13:34:47Z urn:sha1:4c98ef1468f2ead3876a8f886d3a5a33c550a492 This will hopefully allow much caller code to be compiled out. The users (IsParticipant impls) don't generally need to bother with it - they can just ignore it.