-
Notifications
You must be signed in to change notification settings - Fork 33
[Feature Request] Level locking #262
Description
Feature Request
The Problem
Some thought needs to be put into the history system and how threading will effect it.
The history system must work by starting a transaction, making changes and then ending the transaction.
All changes made as part of that transaction are part of that undo operation.
This is very simple if only one operation is running at once because all changes are from that one operation even if it supports threads.
The complexity is introduced if two operations are running in parallel.
The solutions I see are
- Add a lock so only one operation can edit the level at once
- Group the operations into one transaction
- Support both with a switch
We also need to support having no history system in which case the operations can happily run in parallel.
Feature Description
I suggest a global switch that allows switching between serial and parallel operations (if the operations support it) and another to enable or disable the history system.
We also need a lock to be able to stop operations if running in serial mode.
This will also need to allow multiple threads from a single operation to execute.