-
Notifications
You must be signed in to change notification settings - Fork 2
Expand file tree
/
Copy pathuser_output_reentrancy.rs
More file actions
94 lines (83 loc) · 4.02 KB
/
Copy pathuser_output_reentrancy.rs
File metadata and controls
94 lines (83 loc) · 4.02 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
//! Integration tests for `UserOutput` reentrancy fix
//!
//! These tests verify that the `ReentrantMutex` solution prevents deadlocks when
//! acquisitions of `UserOutput` locks would cause deadlocks.
//!
//! ## References
//!
//! - ADR: Use `ReentrantMutex` Pattern for `UserOutput` Reentrancy (docs/decisions/reentrant-mutex-useroutput-pattern.md)
//!
//! ## Problem Context
//!
//! Controller → `ProgressReporter` → `UserOutput` (same thread, multiple acquisitions)
//!
//! ## Solution Components
//!
//! - `Arc<ReentrantMutex<RefCell<UserOutput>>>`: Allows same-thread reentrancy
//! - `RefCell`: Provides interior mutability for `&mut self` `UserOutput` methods
//! - `ReentrantMutex`: Enables same-thread multiple lock acquisitions without deadlock
use std::cell::RefCell;
use std::sync::Arc;
use parking_lot::ReentrantMutex;
use torrust_tracker_deployer_lib::presentation::views::{UserOutput, VerbosityLevel};
/// Test that verifies same-thread reentrancy works without deadlocking
///
/// This test simulates the exact deadlock scenario that occurred in issue #164:
/// 1. Thread acquires `UserOutput` lock (simulating controller context)
/// 2. Same thread tries to acquire `UserOutput` lock again (simulating `ProgressReporter`)
///
/// **Before the fix**: This would deadlock with `std::sync::Mutex`
/// **After the fix**: This works correctly with `parking_lot::ReentrantMutex`
///
/// **Related:**
/// - Issue: <https://github.com/torrust/torrust-tracker-deployer/issues/164>
/// - ADR: Remove `UserOutput` Mutex (docs/decisions/user-output-mutex-removal.md)
#[test]
fn user_output_allows_same_thread_multiple_acquisitions() {
// Create UserOutput using the production pattern that fixed issue #164
let user_output = Arc::new(ReentrantMutex::new(RefCell::new(UserOutput::new(
VerbosityLevel::Silent,
))));
// FIRST ACQUISITION: Simulate controller/error handling context
let lock1 = user_output.lock(); // First lock acquisition
{
let mut output1 = lock1.borrow_mut();
output1.error("Controller acquired lock for error handling");
} // Drop RefCell borrow but keep ReentrantMutex lock
// SECOND ACQUISITION: Simulate ProgressReporter needing the same lock
// This is the critical test - would deadlock with std::sync::Mutex
let lock2 = user_output.lock(); // Same thread, second acquisition
{
let mut output2 = lock2.borrow_mut();
output2.success("ProgressReporter successfully acquired lock - no deadlock!");
}
// If we reach this point without hanging, reentrancy is working correctly
println!("✅ Issue #164 verification: Same-thread multiple acquisitions work");
}
/// Test that verifies `RefCell` provides necessary interior mutability
///
/// `UserOutput` methods require `&mut self`, but `ReentrantMutex` only provides `&T`.
/// `RefCell` bridges this gap by providing interior mutability through runtime borrow checking.
///
/// **Technical Details:**
/// - `ReentrantMutex<UserOutput>` → `&UserOutput` (shared reference)
/// - `RefCell<UserOutput>` → `RefMut<UserOutput>` → `&mut UserOutput` (mutable access)
///
/// **Related:**
/// - Issue: <https://github.com/torrust/torrust-tracker-deployer/issues/164>
/// - ADR: Remove `UserOutput` Mutex (docs/decisions/user-output-mutex-removal.md)
#[test]
fn refcell_enables_mutable_useroutput_methods() {
let user_output = Arc::new(ReentrantMutex::new(RefCell::new(UserOutput::new(
VerbosityLevel::Silent,
))));
// Verify we can call mutable UserOutput methods through RefCell
let lock = user_output.lock();
let mut output = lock.borrow_mut();
// These calls require `&mut self` - would fail without RefCell interior mutability
output.data("RefCell provides interior mutability");
output.warn("Multiple mutable operations work correctly");
output.result("UserOutput methods accessible through shared ReentrantMutex reference");
// Test passes if compilation succeeds and runtime borrows work
println!("✅ RefCell verification: Interior mutability enables &mut self methods");
}