The order in which the RwLocks are currently acquired in meeting is not enforced. The order:
vote_authvotersadmin_authinvite_auth
is only in that order because it was the most practical. Deadlocks could easily arise from changes to endpoints locking in another order (eg voters then vote_auth would deadlock with the logic in start-vote). The order could (and probably should) be enforced at compile time https://www.youtube.com/watch?v=Ba7fajt4l1M&t=1115s
The chances of deadlock is currently quite small, since the system is currently maintained my me, and I know what the order should be, but this should be seen as a future-proofing enhancement.
The order in which the RwLocks are currently acquired in
meetingis not enforced. The order:vote_authvotersadmin_authinvite_authis only in that order because it was the most practical. Deadlocks could easily arise from changes to endpoints locking in another order (eg
votersthenvote_authwould deadlock with the logic instart-vote). The order could (and probably should) be enforced at compile time https://www.youtube.com/watch?v=Ba7fajt4l1M&t=1115sThe chances of deadlock is currently quite small, since the system is currently maintained my me, and I know what the order should be, but this should be seen as a future-proofing enhancement.