Defines interface for object that encapsulates POSIX try_wait semaphore functionality that can be used to synchronize processes in a non-blocking manner
Details
Details
No test plan. Future diffs will use it.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Looks ok, but I don't know obj-c that well. Is there a good reason behind avoiding C++ syntax in this case?
| native/ios/Comm/TemporalMessageStorage/NonBlockingLock.h | ||
|---|---|---|
| 7–8 ↗ | (On Diff #13904) | We should make sure we're being thoughtful about the annotations here. Typically I see a strong or something, but I guess it might be implied? |
| native/ios/Comm/TemporalMessageStorage/NonBlockingLock.h | ||
|---|---|---|
| 7–8 ↗ | (On Diff #13904) | According to docs: https://academy.realm.io/posts/tmi-objective-c-property-attributes/ strong is given by default if not specified. |
Comment Actions
Actually there are not contraindications to implement this functionality in C++. I decided to go with Objective C since we implement this functionality exclusively to solve ios-specific problem. Most code in our project that is ios-specific is written in Objective C, so I followed this pattern. If we ever wish to use this functionality on Android then it is obligatory to implement it in C++ and place somewhere in CommonCpp. However, I don't know whether POSIX semaphores work on Android.
Comment Actions
After quick search https://joekuan.wordpress.com/2017/06/03/using-semaphores-on-android/
If you plan to use semaphores on Android, then don’t. This is because the sem_open, sem_close and sem_unlink are not implemented.
I suggested implementing this in C++ because it is better understood by the team, so the maintainability would be improved. The reusability would be a plus, but it can't be achieved in this case.
So let's keep the Obj-C implementation - I was just curious about the reason here.