gparker42
(Greg Parker)
March 15, 2016, 2:59am
1
Starter bug: SR-946 Unify mutexes in the Swift runtime.
opened 03:54AM - 15 Mar 16 UTC
closed 04:38AM - 27 Jul 19 UTC
Improvement
StarterBug
Standard Library
Runtime
| | |
|------------------|-----------------|…
|Previous ID | SR-946 |
|Radar | rdar://25058486 |
|Original Reporter | @gparker42 |
|Type | Improvement |
|Status | Resolved |
|Resolution | Done |
<details>
<summary>Additional Detail from JIRA</summary>
| | |
|------------------|-----------------|
|Votes | 0 |
|Component/s | Standard Library |
|Labels | Improvement, Runtime, StarterBug |
|Assignee | None |
|Priority | Medium |
md5: af9f82a35d32e960d03bb405bb35fd8d
</details>
**Issue Description:**
The Swift runtime uses two different mutexes internally. Neither one is good. We should write a new swift::mutex or adopt some LLVM mutex that solves these problems.
Some code uses C++ std::mutex. This mutex throws exceptions when errors occur. Nobody can reasonably catch and respond to these errors. Backtraces are lost when these exceptions are caught and re-thrown before the process halts (such as rdar://25058486, probably).
Some code uses pthread_mutex_t. This mutex returns non-zero when errors occur. Our code does not check these errors.
The new mutex implementation should:
- use pthread_mutex_t or some LLVM mutex if a suitable one is available
- implement C++ STL's BasicLockable and Lockable
- halt using swift::reportError when a failure occurs
- not throw exceptions
"The Swift runtime uses two different mutexes internally. Neither one is good. We should write a new swift::mutex or adopt some LLVM mutex that solves these problems. ..."
···
--
Greg Parker gparker@apple.com Runtime Wrangler