02-15-2012, 03:05 AM
Special implementations sound ok, as long as there aren't too many. I wouldn't have wanted to call something like:
Instead, we'll keep the SetBlock() function, calling this instead:
However, those callback classes are still useful - see the webplugin's cWebAdmin.cpp, class cPlayerAccum. It includes a string buffer into which all the players are accummulated, HTML-formatted, one-by-one, in a single function call. Thread-safe and everything.
The thread safety is of utmost importance here - the ForEachXXX() function needs to lock the list of objects it is working on, process the callbacks and unlock the list - so that no other thread can manipulate the list under its hands.
Calling Lock, GetAll, Process, Unlock is not a good solution because someone, somewhere is always gonna forget to lock or unlock (and RAII doesn't work well for this)
Finally, I have a vision that the future cChunkMap object will not let a single cChunkPtr out of it, it will only accept coordinates and actions as the parameters for all its functions. Thus, it could finally be pronounced thread-safe, including chunk access
I think the current "bad compressed data format" errors are the result of two threads colliding on a single chunk - one thread writes blockdata, the other thread is in the compressino routine. The compression looks at a value, decides to use some algorithm on it and before the algorithm starts, the value gets changed by the other thread -> bang, invalid compressed data. I'll get working on this issue as soon as possible.
Code:
m_World->DoInChunk(ChunkX, ChunkZ, cSetBlock(BlockX, BlockY, BlockZ, E_BLOCKID_IRONORE));Code:
m_world->SetBlock(BlockX, BlockY, BlockZ, E_BLOCKID_IRONORE);However, those callback classes are still useful - see the webplugin's cWebAdmin.cpp, class cPlayerAccum. It includes a string buffer into which all the players are accummulated, HTML-formatted, one-by-one, in a single function call. Thread-safe and everything.
The thread safety is of utmost importance here - the ForEachXXX() function needs to lock the list of objects it is working on, process the callbacks and unlock the list - so that no other thread can manipulate the list under its hands.
Calling Lock, GetAll, Process, Unlock is not a good solution because someone, somewhere is always gonna forget to lock or unlock (and RAII doesn't work well for this)
Finally, I have a vision that the future cChunkMap object will not let a single cChunkPtr out of it, it will only accept coordinates and actions as the parameters for all its functions. Thus, it could finally be pronounced thread-safe, including chunk access
I think the current "bad compressed data format" errors are the result of two threads colliding on a single chunk - one thread writes blockdata, the other thread is in the compressino routine. The compression looks at a value, decides to use some algorithm on it and before the algorithm starts, the value gets changed by the other thread -> bang, invalid compressed data. I'll get working on this issue as soon as possible.