#[cfg(feature = "debug_atomic_refcell")] ?

Open
#16 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
32/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
rust
Domain
tooling

Research direction

Start by comparing this crate's thread-safe RefCell implementation with the original RefCell implementation and its debug_refcell feature. Determine whether borrowed_at information can be retained safely, then define the debug-build behavior and verify that borrow errors report the earliest active borrow location without compromising multi-threaded use.

Written by the indexing model from the issue text.

Description

In the original RefCell implementation there is a cfg feature called "debug_refcell", which in case of a panic allows to see where a RefCell was first borrowed:

pub struct RefCell<T: ?Sized> {
    borrow: Cell<BorrowFlag>,
    // Stores the location of the earliest currently active borrow.
    // This gets updated whenever we go from having zero borrows
    // to having a single borrow. When a borrow occurs, this gets included
    // in the generated `BorrowError/`BorrowMutError`
    #[cfg(feature = "debug_refcell")]
    borrowed_at: Cell<Option<&'static crate::panic::Location<'static>>>,
    value: UnsafeCell<T>,
}

I read that you stripped RefCell of everything that conflicted multi-thread environment. Is it because of this that the debug feature was removed? Is it hard to reimplement it back? Pushing borrow checking into runtime leaves us with less info to investigate things. This leads projects like accountable-refcell to store the whole stack trace per RefCell. Well, that much of an overhead is probably overkill, but to have the minimal "borrowed_at" info is an essential thing to have for debug builds, don't you think?🤔

Dominant language
Rust
Stars
103
Forks
22
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from mozilla/atomic_refcell

All issues in mozilla/atomic_refcell

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.