Skip to content

[Feature Request] Level locking #262

@gentlegiantJGC

Description

@gentlegiantJGC

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

  1. Add a lock so only one operation can edit the level at once
  2. Group the operations into one transaction
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions