| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
lgtm with one comment.
Sorry, something went wrong.
|
@jmachowinski do we want to backport the similar fix to jazzy and humble without changing function signature? |
Sorry, something went wrong.
This would be a behavior change, so I think we can't backport |
Sorry, something went wrong.
|
Pulls: #2767 |
Sorry, something went wrong.
Sorry, something went wrong.
|
@ahcorde I think rerunning the CI won't change the result. I need to investigate whats going on, but did not find time yet... |
Sorry, something went wrong.
Up until this change, after the call to remove node, entities of a node might still be in the use by the executor. Therefore direct deletion of the node after the call might result in a memory violation if an entity would do a callback into the node itself. From now on, by default the remove_node will be blocking until all entities are released by the executor, which should be the expected behavior for most users. Signed-off-by: Janosch Machowinski <J.Machowinski@cellumation.com>
|
Pulls: #2767 |
Sorry, something went wrong.
|
rerunning CI to get the failing tests, old logs seems to have been deleted |
Sorry, something went wrong.
There was a problem hiding this comment.
Do you mind to merge with rolling ?
Sorry, something went wrong.
|
This patch causes unwanted side effects, and I did not find time to rework it yet |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Up until this change, after the call to remove node, entities of a node might still be in the use by the executor. Therefore direct deletion of the node after the call might result in a memory violation if an entity would do a callback into the node itself. From now on, by default the remove_node will be blocking until all entities are released by the executor, which should be the expected behavior for most users.
This commit fixes #2749