Jump to content
TrinityCore

Search the Community

Showing results for tags 'member'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Releases and Announcements
  • Help and Support
    • Help and Support
  • Offtopic
    • Trinitycore.org Website issues
    • Chillout Room

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 1 result

  1. I was trying to locate if Group::Disband is safe to call anywhere or if it is not thread safe. My assumption was that it is not thread safe since it is calling ObjectAccessor::FindConnectedPlayer, Player::GetGroup and Player::SetGroup I tried tracking where Group::Disband is called and everywhere it was in opcode handlers that were marked as threadunsafe. However I found one or more that were not threadunsafe. WorldSession::HandleBfEntryInviteResponse is STATUS_LOGGEDIN, PROCESS_INPLACE, which would mean it is executed when received. And since it seems packets are handled on a separate thread the code must be safe to call anywhere (is thread safe). The function however calls Battlefield::PlayerAcceptInviteToWar which calls Battlefield::AddOrSetPlayerToCorrectBfGroup which calls Group::RemoveMember which calls Group::Disband and that was assumed not to be thread safe. Conclusion is that if someone sends the packet for HandleBfEntryInviteResponse and someone in the same group is also removed from the group in any other code (for example the normal group leave opcode?) it would cause a race condition. Is there something guaranteeing the safety or is this a possible race condition? FFR: I used 3.3.5a https://github.com/TrinityCore/TrinityCore/commit/239f0b4ad0e83da9d31c8031aa2e50c294bfc913
×
×
  • Create New...