Brief summary of issue / Description of requested feature:
Currently some parts of the Host class are protected against conflicting access via a QMutex; however as things develop we will increasingly run into the risk of more than one thread trying to access those members simultaneously. In the majority of cases it is anticipated that those changes may be read rather than write operations but that access control system does not differentiate between those two types of operation and we run the risk of hitting a deadlock situation when two threads both want to access that class.
In my opinion it would be worthwhile to change to a Shared-Read/Exclusive-Write model of operation for the Host class (as I have previously done in the HostManager class) so that only accesses that need to modify a class member need to gain permission to do so whereas any read operation can be accepted (unless there is such a write operation in progress) - this will need a switch to a QReadWriteLock perhaps in conjunction with the QReadLocker and QWriteLocker helpers which operate in a similar manner to the QLocker class does with a QMutex...
Steps to reproduce the issue / Reasons for adding feature:
- Reduce the chances of hitting deadlock situations in a class that is at the centre of the individual MUD/Game Profiles session.
Error output / Expected result of feature
Improve the application as we develop multi-threaded based features (e.g. back-ground saving, enhanced route-finding, better profile sandboxing {so activity in one profile does not delay a second one})
Extra information, such as Mudlet version, operating system and ideas for how to solve / implement:
As described above - replace QMutex with QReadWriteLock, and replace QMutexLocker with QReadLocker/QWriteLocker as appropriate or for some cases where there can be workarounds for failing to get access to a Host class member at any particular moment (possibly do something else and then try again?) use a more nuanced tryForLock(Read|Write)(...) with or without a timeout...
Brief summary of issue / Description of requested feature:
Currently some parts of the
Hostclass are protected against conflicting access via aQMutex; however as things develop we will increasingly run into the risk of more than one thread trying to access those members simultaneously. In the majority of cases it is anticipated that those changes may be read rather than write operations but that access control system does not differentiate between those two types of operation and we run the risk of hitting a deadlock situation when two threads both want to access that class.In my opinion it would be worthwhile to change to a Shared-Read/Exclusive-Write model of operation for the
Hostclass (as I have previously done in theHostManagerclass) so that only accesses that need to modify a class member need to gain permission to do so whereas any read operation can be accepted (unless there is such a write operation in progress) - this will need a switch to aQReadWriteLockperhaps in conjunction with theQReadLockerandQWriteLockerhelpers which operate in a similar manner to theQLockerclass does with aQMutex...Steps to reproduce the issue / Reasons for adding feature:
Error output / Expected result of feature
Improve the application as we develop multi-threaded based features (e.g. back-ground saving, enhanced route-finding, better profile sandboxing {so activity in one profile does not delay a second one})
Extra information, such as Mudlet version, operating system and ideas for how to solve / implement:
As described above - replace
QMutexwithQReadWriteLock, and replaceQMutexLockerwithQReadLocker/QWriteLockeras appropriate or for some cases where there can be workarounds for failing to get access to aHostclass member at any particular moment (possibly do something else and then try again?) use a more nuancedtryForLock(Read|Write)(...)with or without a timeout...