AudioSourceProviderAVFObjC locks a mutex in destructor. This is undefined behavior, since the mutex controls access to the object members. Since the object cannot have multiple active references during destruction, mutex locking should not be needed. However, it is needed, and as such this indicates undefined behavior.´
> This is undefined behavior, since the mutex controls access to the object members. Object members are destroyed after the destructor runs, so I don't see a problem with this code.
> > This is undefined behavior, since the mutex controls access to the object members. > > Object members are destroyed after the destructor runs, so I don't see a > problem with this code. Yeah, you're right. I took a bit of a mental shortcut, thinking about the case where the mutex would be moved to the class for more logical operation. I'll use this bug to remove the comment.
Ah, no, maybe not. I think the issue still stands. > Object members are destroyed after the destructor runs, so I don't see a problem with this code. It's not about destroying the members. The bug is about what C++ defines as being "well-formed program". I think I recall, and it sort of makes sense, that a well-formed program cannot have the execution in destructor and a member function at the same time. In practice it works, as the data members are destroyed after end of the destructor. However, typically one should not rely on "in practice it works" if it's contrary to the soundness definition of the language.
Clarified it: I was remembering and thinking wrong. So I'll remove the comment in the destructor.
<rdar://problem/76894075>