This repository has been archived by the owner on Aug 8, 2023. It is now read-only.
Scope threads to an Environment #1015
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Argh, ignore it for now, I forgot to push the change that make it return references. |
|
@kkaefer PTAL, I'm using reference as much as I can, but not on the ThreadInfo struct because I need to be able to store env = nullptr for the Main thread (that doesn't run on a Environment::Scope). |
The Environment will now keep track of every thread that is running within a Environment::Scope. Once the Scope object is created, it will automatically register the thread to the ThreadInfoStore with some additional information and it will automatically deregister as the stack frame rewinds (which can be useful for Threads that are temporally in use by an Environment like Workers). The ThreadInfoStore could be using the thread-local storage, but I think that making the Environment aware of what threads are associated to it can be useful for writing a mechanism for posting messages between threads. Withing a Scope, the Environment associated to the thread can be queried at any time which will save us from juggling a reference to the Environemnt around. Finally, the type of thread (Main, Map, etc) can also be queried at any moment to make sure a piece of code is running on the desired thread.
Also, replace manual thread type checks with Environment::currentlyOn().
We are also removing the code that is passing the Environment around and instead, we get now the Environment in the TileData using Environment::Get(). When processing the job, the work will be temporally registered to the Environment as "TileWorker_0/0/0" which can be used for logging in the future. At the end of the job, it gets unregistered automatically from the Environment.
Environment will now have an incremental unique ID to that will help distinguish between threads scoped to different Environments when logging.
To make it easier to debug, add the Environment ID and the Thread name
to the log messages. For instance log messages from the TileParser will look like:
[WARNING] {0}{TileWorker_15/18653/9486}[ParseTile]: some relevant warning message
| | | |
| | | +-> Component
| | +--------------------> Thread name
| +----------------------------------> Environment ID
+------------------------------------------> Severity level
Log messages that are not inside an Environment::Scope will work
normally and will look like:
[WARNING] [JNI]: some relevant warning message
Fixes #882.
kkaefer
added a commit
that referenced
this pull request
Mar 18, 2015
Scope threads to an Environment
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
By creating an Environment::Scope at the beginning of the thread, it will automatically register it to the Environment during its lifespan. The Main thread is registered automatically at startup.
Threads running within an Environment::Scope can at any moment query for the Environment and assert what is the current thread, to make sure the code is being executed on the right thread.
And finally, log messages will now show the Environment ID and the current thread name.