summaryrefslogtreecommitdiffstats
path: root/source
diff options
context:
space:
mode:
authormadmaxoft@gmail.com <madmaxoft@gmail.com@0a769ca7-a7f5-676a-18bf-c427514a06d6>2013-06-16 10:51:05 +0200
committermadmaxoft@gmail.com <madmaxoft@gmail.com@0a769ca7-a7f5-676a-18bf-c427514a06d6>2013-06-16 10:51:05 +0200
commit588d4dc9073d884398a13557267743665f0f16c4 (patch)
tree0f9731804a1ebe57d652f6da8d871cb793d45686 /source
parentSocket: Removed the absurd function returning localhost addr, now using INADDR_LOOPBACK (diff)
downloadcuberite-588d4dc9073d884398a13557267743665f0f16c4.tar
cuberite-588d4dc9073d884398a13557267743665f0f16c4.tar.gz
cuberite-588d4dc9073d884398a13557267743665f0f16c4.tar.bz2
cuberite-588d4dc9073d884398a13557267743665f0f16c4.tar.lz
cuberite-588d4dc9073d884398a13557267743665f0f16c4.tar.xz
cuberite-588d4dc9073d884398a13557267743665f0f16c4.tar.zst
cuberite-588d4dc9073d884398a13557267743665f0f16c4.zip
Diffstat (limited to 'source')
-rw-r--r--source/ClientHandle.cpp13
1 files changed, 12 insertions, 1 deletions
diff --git a/source/ClientHandle.cpp b/source/ClientHandle.cpp
index 9d5bbaeaf..cbe544c1f 100644
--- a/source/ClientHandle.cpp
+++ b/source/ClientHandle.cpp
@@ -1959,7 +1959,18 @@ void cClientHandle::DataReceived(const char * a_Data, int a_Size)
// Data is received from the client, hand it off to the protocol:
if ((m_Player != NULL) && (m_Player->GetWorld() != NULL))
{
- // Lock the world, so that plugins reacting to protocol events have already the chunkmap locked
+ /*
+ _X: Lock the world, so that plugins reacting to protocol events have already the chunkmap locked.
+ There was a possibility of a deadlock between SocketThreads and TickThreads, resulting from each
+ holding one CS an requesting the other one (ChunkMap CS vs Plugin CS) (FS #375). To break this, it's
+ sufficient to break any of the four Coffman conditions for a deadlock. We'll solve this by requiring
+ the ChunkMap CS for all SocketThreads operations before they lock the PluginCS - thus creating a kind
+ of a lock hierarchy. However, this incurs a performance penalty, we're de facto locking the chunkmap
+ for each incoming packet. A better, but more involved solutin would be to lock the chunkmap only when
+ the incoming packet really has a plugin CS lock request.
+ Also, it is still possible for a packet to slip through - when a player still doesn't have their world
+ assigned and several packets arrive at once.
+ */
cWorld::cLock(*m_Player->GetWorld());
m_Protocol->DataReceived(a_Data, a_Size);