DS's insistence to send broadcast type messages has had a history of deadlocking the daemon threads. There have been some inferior workarounds that punish players who are on crappy connections (namely, they are disconnected if they cause the daemon thread to block). This is what I consider the best fix for the situation.
Auth and game clients now have another DS::MsgChannel for srv2cli broadcasts. MsgChannel's semaphore was changed to an eventfd, which we use poll the socket and eventfd for client and server communication, respectively. The downside is that broadcast messages are now required to be allocated on the heap and refcounted. The plus side is that clients are not punished for being a little slow to handle messages, which is fairly important in cases with lots of messages flying around (eg lots of players linking out from something like a door run). I was also able to toss mutexes guarding the RC4 state and the socket send state because we only write from the client thread now
DS's insistence to send broadcast type messages has had a history of deadlocking the daemon threads. There have been some inferior workarounds that punish players who are on crappy connections (namely, they are disconnected if they cause the daemon thread to block). This is what I consider the best fix for the situation.
Auth and game clients now have another
DS::MsgChannelfor srv2cli broadcasts. MsgChannel's semaphore was changed to an eventfd, which we use poll the socket and eventfd for client and server communication, respectively. The downside is that broadcast messages are now required to be allocated on the heap and refcounted. The plus side is that clients are not punished for being a little slow to handle messages, which is fairly important in cases with lots of messages flying around (eg lots of players linking out from something like a door run). I was also able to toss mutexes guarding the RC4 state and the socket send state because we only write from the client thread now