Skip to content

Conversation

@AtnNn
Copy link
Member

@AtnNn AtnNn commented Apr 29, 2017

terminate_internal modifies the entry->state asynchronously, without holding a lock on the entry.

This might be what caused the guarantee failure in #6333

  • I have read and agreed to the CLA

@AtnNn AtnNn added this to the 2.3.x milestone Apr 29, 2017
@AtnNn AtnNn requested a review from Tryneus April 29, 2017 16:50
@srh
Copy link
Contributor

srh commented May 9, 2017

In principle this looks good to me. But note that in ~ref_t there is a guarantee(entry->state != entry_t::state_t::START) there. That seems like it might now fail, no?

@srh srh modified the milestones: 2.3.6, 2.3.x Jun 22, 2017
@AtnNn AtnNn modified the milestones: 2.3.x, 2.3.6 Jul 11, 2017
@srh srh mentioned this pull request Dec 11, 2017
1 task
@srh
Copy link
Contributor

srh commented Dec 11, 2017

Fixed by #6564 (which is built off these changes).

@srh srh closed this Dec 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants