Unbox mutexes and condvars on some platforms by m-ou-se · Pull Request #77380 · rust-lang/rust (original) (raw)
…ex, r=dtolnay
Split sys_common::Mutex in StaticMutex and MovableMutex.
The (unsafe) Mutex
from sys_common
had a rather complicated interface. You were supposed to call init()
manually, unless you could guarantee it was neither moved nor used reentrantly.
Calling destroy()
was also optional, although it was unclear if 1) resources might be leaked or not, and 2) if destroy()
should only be called when init()
was called.
This allowed for a number of interesting (confusing?) different ways to use this Mutex
, all captured in a single type.
In practice, this type was only ever used in two ways:
As a static variable. In this case, neither
init()
nordestroy()
are called. The variable is never moved, and it is never used reentrantly. It is only ever locked using theLockGuard
, never withraw_lock
.As a
Box
ed variable. In this case, bothinit()
anddestroy()
are called, it will be moved and possibly used reentrantly.
No other combinations are used anywhere in std
.
This change simplifies things by splitting this Mutex
type into two types matching the two use cases: StaticMutex
and MovableMutex
.
The interface of both new types is now both safer and simpler. The first one does not call nor expose init
/destroy
, and the second one calls those automatically in its new()
and Drop
functions. Also, the locking functions of MovableMutex
are no longer unsafe.
This will also make it easier to conditionally box mutexes later, by moving that decision into sys/sys_common. Some of the mutex implementations (at least those of Wasm and 'sys/unsupported') are safe to move, so wouldn't need a box. (But that's blocked on rust-lang#76932 for now.) (See rust-lang#77380.)