WIP: Remove warnings #102
WIP: Remove warnings #102
Conversation
niil-ohlin
force-pushed
the
remove-warnings
branch
from
e16dd51
to
c8d4a96
Compare
| @@ -21,20 +21,22 @@ public final class Callbacker<Value> { | |||
|
|
|||
| private var callbacks = Callbacks.none | |||
| private var _mutex = pthread_mutex_t() | |||
| private var mutex: PThreadMutex { return PThreadMutex(&_mutex) } | |||
There was a problem hiding this comment.
Are you allowed to add extension to PThreadMutex (UnsafeMutablePointer<pthread_mutex_t>)? Otherwise perhaps create a thin wrapper around it and use that instead?
There was a problem hiding this comment.
good idea! I'll try that!
niil-ohlin
force-pushed
the
remove-warnings
branch
3 times, most recently
from
0397903
to
d26589b
Compare
| } | ||
|
|
||
| mutating func unlock() { | ||
| withPointer { $0.unlock() } | ||
| } |
There was a problem hiding this comment.
Why not add protect as well, to avoid rewriting a lot of code?
There was a problem hiding this comment.
It caused crashes when I used protect. I'm not a 100% sure why though.
There was a problem hiding this comment.
How did your code look like and did the log specify why it crashed (e.g. exclusivity violation)?
| @@ -10,8 +10,7 @@ import Foundation | |||
|
|
|||
| /// A reference wrapper around a POSIX thread mutex | |||
| public final class Mutex { | |||
| private var _mutex = pthread_mutex_t() | |||
| private var mutex: PThreadMutex { return PThreadMutex(&_mutex) } | |||
| private var mutex = pthread_mutex_t() | |||
There was a problem hiding this comment.
I saw this comment:
/// Helper methods to work directly with a Pthread mutex pointer to avoid overhead of alloction and reference counting of using the Mutex reference type.
/// - Note: You have to explicity call `initialize()` before use (typically in a class init) and `deinitialize()` when done (typically in a class deinit)
extension UnsafeMutablePointer where Pointee == pthread_mutex_t {I'm trying to remember what the reason we the pthread_mutex_t -> PThreadMutex dance above, and if this change will alter the behaviour are performance...
There was a problem hiding this comment.
Hmm, ok this solution might not be correct at all. I thought that because private var mutex: PThreadMutex { return PThreadMutex(&_mutex) } would create a new UnsafeMutablePointer every time you called it. It would be functionally the same as withUnsafeMutablePointer(to: &_mutex) { ... } but it seems to change behavior.
There was a problem hiding this comment.
@niil-ohlin do you remember why this didn't work? I opened #104 now and saw your PR
moglistree
force-pushed
the
remove-warnings
branch
from
5eaa296
to
797072b
Compare
moglistree
force-pushed
the
master
branch
2 times, most recently
from
deccedd
to
65d4f58
Compare
A solution for removing warnings. I really don't like this solutions. It's way to naive and hacky and really degrades the quality of the codebase. Does anyone have a suggestion for how the mutex warnings can be addressed?