Conversation
|
Starting build on |
|
@etejedor Could you take a look? |
| // individually anyway ... | ||
|
|
||
| R__LOCKGUARD2(gInterpreterMutex); | ||
| R__LOCKGUARD(gInterpreterMutex); |
There was a problem hiding this comment.
Should we also apply the same fix to all occurrences of R__LOCKGUARD_IMT2 and replace them by R__LOCKGUARD_IMT?
There was a problem hiding this comment.
It depends on whether the mutex guard is guaranteed to be initialized or not ....
|
Starting build on |
|
Build failed on ubuntu14/native. Failing tests: |
|
Build failed on mac1012/native. Failing tests: |
|
Build failed on slc6/gcc62. Failing tests: |
|
Build failed on slc6/gcc49. Failing tests: |
|
Build failed on centos7/gcc49. Failing tests: |
|
If my two minor comments are addressed this pr for me is ready to go. |
|
@dpiparo I don't see the comments. Besides, after further development, I found the need also make the lock re-entrant from Read to Write lock making it relatively heavy so I am planning to actually separate the simple RW lock from the re-entrant one. So once I find (and address) the comments, I will close this. |
…actual re-entrancy
…ath. well used for every call to RecursiveRemove
|
@phsft-bot build please. |
|
Starting build on |
1 similar comment
|
Starting build on |
|
Build failed on ubuntu14/native. Warnings:
Failing tests: |
|
Build failed on slc6/gcc62. Warnings:
Failing tests: |
|
Build failed on slc6/gcc49. Warnings:
Failing tests: |
|
Build failed on mac1012/native. Warnings:
Failing tests: |
4 participants
One pending question (beside whether this is performant enough) is whether to keep the old TRWSpinLock and the new TRWSpinLock (Reentrant) or to have them (as in this MR) the same.