run destructors for .threadvars on thread exit
#1308
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
Two new module operators are introduced: * the `threadDeinit` operator (module-level threadvar destruction) * the `threadPostDeinit` operator (procedure-scoped threadvar destruction) Both are similar to the `Deinit` and `PostDeinit` operators. Module- level threadvars are destroyed after top-level globals but before procedure-scoped threadvars and globals. For slightly simpler code generation, destruction of procedure-scoped threadvars is intertwined with that of procedure-scoped globals (in the `PostDeinit` procedure).
The procedure uses a fixed name so that the `threads` module can then import it.
The destructors are called *after* manually registered thread destruction handlers, as those could rely on threadvars.
zerbina
added
bug
I was just about to ask about this, because the order seems backwards -- sounds good, it can be discussed elsewhere. |
saem
approved these changes
May 13, 2024
|
/merge |
|
Merge requested by: @saem Contents after the first section break of the PR description has been removed and preserved below:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
All
.threadvarss that have destructors are now destroyed on threadexit (including the main thread). Module-level
.threadvars aredestroyed before procedure-scoped
.threadvars, mirroring thedestruction order of non-threadlocal globals.
Fixes #1301.
Details
Two new module operators are introduced:
ThreadDeinit(destroys all module-level.threadvars)ThreadPostDeinit(destroys all procedure-scoped.threadvars)They have the same role for
.threadvars asDeinitandPostDeinitdo for normal globals. In order to make implementation slightly
simpler, destruction of procedure-scoped
.threadvars is also done aspart
PostDeinit. This means thatThreadPostDeinitdoesn't have tobe called on program teardown.
Finally,
cbackend(the other backends don't support threads at themoment) generates and emits the
nimTeardownThreadVarsprocedure,which is then importc'ed by
threadsand run after the destructioncallbacks (which might use threadvars themselves).
Since all backends use
backends.generateMain(either directly orindirectly), destruction of
.threadvars also automatically works withthe JS and VM backends.