-
Type: Improvement
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Server Programmability
There's a file-local singleton of MallocFreeOStream.
Currently need to be holding a MallocFreeOStreamGuard to synchronize access to it, and there's a singleton lock. About 5 functions currently need their caller to hold the lock on the mallocFreeOStream and say so with comments.
So there's a duplication of singleton-ness here.
The MallocFreeOStreamGuard has a few static members:
static inline stdx::mutex _streamMutex; static inline std::function<void(int)> _onDeadlock;
But there's also the namespace-scope singleton instance:
MallocFreeOStream mallocFreeOStream;
We could make this system self-documenting by having the MallocFreeOStreamGuard be the only way to obtain a reference to a MallocFreeOStream, and remove the mallocFreeOStream variable.
It would become a singleton static of the guard class along with the others.
Then you wouldn't be able to compile any accesses to the singleton MallocFreeOStream instance without going through the proper synchronization. We wouldn't be relying on comments or WithLock style informal idioms.
This would be similar in spirit to a synchronized_value, where you have to go through an UpdateGuard to access the value, and the UpdateGuard has a unique_lock member, so the only way to get the value& is through locking properly.
We won't necessarily have to have one MallocFreeOStream instance. But if we have more than one at some point, accesses to each would need to synchronize, and I think that making the Guard be the way to get at a stream value is the way to do that.