Skip to content

Conversation

@georgemitenkov
Copy link
Contributor

@georgemitenkov georgemitenkov commented Feb 6, 2026

Description

Global context template for execution, as described in design doc but simpler. Instead of atomics, implemented via RwLock so no unsafe is needed. On execution (block), read-lock is acquired. For maintenance (between blocks), write-lock is acquired. Added a few tests for that. Note: Context will be populated with data and caches, with unsafe APIs which are safe through execution or maintenance guard implementations.

How Has This Been Tested?

Unit tests added.

Key Areas to Review

Type of Change

  • New feature
  • Bug fix
  • Breaking change
  • Performance improvement
  • Refactoring
  • Dependency update
  • Documentation update
  • Tests

Which Components or Systems Does This Change Impact?

  • Validator Node
  • Full Node (API, Indexer, etc.)
  • Move/Aptos Virtual Machine
  • Aptos Framework
  • Aptos CLI/SDK
  • Developer Infrastructure
  • Move Compiler
  • Other (specify)

Checklist

  • I have read and followed the CONTRIBUTING doc
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I identified and added all stakeholders and component owners affected by this change as reviewers
  • I tested both happy and unhappy path of the functionality
  • I have made corresponding changes to the documentation

Note

Medium Risk
Introduces new cross-thread synchronization primitives and timing-based concurrency tests; while currently a placeholder, future consumers may rely on the lock semantics and could hit contention/starvation issues if misused.

Overview
Adds a new global-context MonoMove crate that introduces a GlobalContext with a two-phase locking API: non-blocking acquisition of shared ExecutionContext read guards for parallel execution, and exclusive MaintenanceContext write guards for between-block maintenance.

Wires the crate into the workspace (Cargo.toml and Cargo.lock) and adds integration tests validating concurrent execution access and mutual exclusion between execution and maintenance phases.

Written by Cursor Bugbot for commit e753a18. This will update automatically on new commits. Configure here.

Copy link
Contributor Author

georgemitenkov commented Feb 6, 2026

This stack of pull requests is managed by Graphite. Learn more about stacking.

@georgemitenkov georgemitenkov mentioned this pull request Feb 9, 2026
22 tasks
@georgemitenkov georgemitenkov marked this pull request as ready for review February 9, 2026 11:56
Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.

.map(|_| {
let ctx = Arc::clone(&ctx);
thread::spawn(move || {
let _guard = ctx.execution_context();
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simulation test silently ignores failed lock acquisitions

Medium Severity

In test_block_execution_simulation, both execution_context() and maintenance_context() return Option values that are silently assigned without .expect() or any assertion. If lock acquisition fails (returns None), the test passes without actually holding any guard, defeating the purpose. Every other test in this file uses .expect() to verify successful acquisition.

Additional Locations (1)

Fix in Cursor Fix in Web

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant