-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Move environment functionality to utils #30
Conversation
Signed-off-by: Michael Carroll <michael@openrobotics.org>
Signed-off-by: Michael Carroll <michael@openrobotics.org>
Codecov Report
@@ Coverage Diff @@
## ign-utils1 #30 +/- ##
==============================================
+ Coverage 94.00% 94.36% +0.36%
==============================================
Files 3 4 +1
Lines 50 71 +21
==============================================
+ Hits 47 67 +20
- Misses 3 4 +1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with green CI
Signed-off-by: Michael Carroll <michael@openrobotics.org>
041c3ea
to
166cd35
Compare
Signed-off-by: Michael Carroll <michael@openrobotics.org>
166cd35
to
5d2e73f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. The only caveat is that I don't think env
and setenv
are thread safe since the underlying functions are not. I'm not referring to the issue of a global char *
getting invalidated by multiple calls to getenv
from different threads, but the data race that can occur when both setenv
and getenv
are called from different threads. The windows documentation recommends synchronizing calls to these functions. cppreference for getenv
says:
This function is thread-safe (calling it from multiple threads does not introduce a data race) as long as no other function modifies the host environment. In particular, the POSIX functions setenv(), unsetenv(), and putenv() would introduce a data race if called without synchronization.
Perhaps we can just document this in Environment.hh
.
Signed-off-by: Michael Carroll <michael@openrobotics.org>
Added documentation. |
Signed-off-by: Michael Carroll <michael@openrobotics.org>
This pull request has been mentioned on Gazebo Community. There might be relevant details there: https://community.gazebosim.org/t/new-ignition-releases-2022-03-01-citadel-edifice-fortress/1313/1 |
Since multiple ignition libraries make use of setting/getting environment variables, it makes more sense to locate it here.