rust-lang / rust-lang/rfcs

Adding locks disregarding poison

Open
#3,378 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Markdown
Stars
6.6k
Forks
1.7k
Avg merge
16h 14m
Merged PRs (30d)
1

Description

Currently, if you are to use any of the locks provided by the standard library, you are forced to handle lock poisoning

use std::sync::*;

let hello = Mutex::new(2);

std::thread::scope(|s| {
    s.spawn(|| {
        let _guard = hello.lock();
        panic!("Ups!");
    });

    // May return `Err`, if `_guard` is obtained before `guard2`
    let guard2: LockResult<MutexGuard<T>> = hello.lock();
})

Most of the time you aren't really interested in maneging these, so you're left with two options.

You can unwrap the result, hoping no previous holder has panicked.

use std::sync::*;

let hello = Mutex::new(2);

std::thread::scope(|s| {
    s.spawn(|| {
        let _guard = hello.lock();
        panic!("Ups!");
    });

    // May panic, if `_guard` is obtained before `guard2` 
    let guard2: MutexGuard<T> = hello.lock().unwrap();
})

Or you can force the error to return you the lock

use std::sync::*;

let hello = Mutex::new(2);

std::thread::scope(|s| {
    s.spawn(|| {
        let _guard = hello.lock();
        panic!("Ups!");
    });

    // Never panics
    let guard2: MutexGuard<T> = match hello.lock() {
        Ok(x) => x,
        Err(e) => e.into_inner()
    };
})

Ideally, you should be using the last example if you aren't interested in maneging poisonous locks, but having to make the same match expression every time you want to lock is very cumbersome, so perhaps we should add a method that makes the lock without checking if it's poisoned.

use std::sync::*;

let hello = Mutex::new(2);

std::thread::scope(|s| {
    s.spawn(|| {
        let _guard = hello.lock();
        panic!("Ups!");
    });

    // Never panics (name is an example, and I'm sure a better one exists)
    let guard2: MutexGuard<T> = hello.lock_deep();
})

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.

Research direction

The issue names std::sync::{Mutex, MutexGuard, LockResult} and the lock() API; begin by reviewing their existing poisoning behavior and related standard-library conventions. Define the proposed non-poisoning lock API and its semantics, then capture the decision in an RFC with updated examples and tests where applicable.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design, operating-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.