Make usage of stateful patterns thread-safe

[SirYwell]

Overview

Description

Some patterns make use of MutableBlockVector or might delegate to patterns that might do so, therefore we need to fork it to prevent race conditions.

The example command //set #!z[#linear2d[white_wool,2%light_gray_wool,4%gray_wool,8%black_wool]] and how it looks:

Before:

With this change:

Submitter Checklist

Edit tasklist title

Beta Give feedback Tasklist Submitter Checklist, more options

• Rename
• Copy markdown
• Delete tasklist

Delete tasklist

Delete tasklist block?

Are you sure? All relationships in this tasklist will be removed.

Cancel Delete

1. Make sure you are opening from a topic branch (**/feature/fix/docs/ branch** (right side)) and not your main branch.

   Make sure you are opening from a topic branch (/feature/fix/docs/ branch (right side)) and not your main branch.
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
2. Ensure that the pull request title represents the desired changelog entry.

   Ensure that the pull request title represents the desired changelog entry.
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
3. New public fields and methods are annotated with `@since TODO`.

   New public fields and methods are annotated with @since TODO.
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove
4. I read and followed the [contribution guidelines](https://github.com/IntellectualSites/.github/blob/main/CONTRIBUTING.md).

   I read and followed the contribution guidelines.
   Options

   • Convert to issue
   • Toggle completion
   • Rename
   • Remove

Add item to Submitter Checklist

[dordsor21]

This wouldn't work if the patterns are nested within another pattern. We ought to create an AbstractDelegatePattern and override fork in there and ensure all patterns with nested patterns utilise this

[SirYwell]

Good point, I'll look into it.

[SirYwell]

I went for an interface StatefulPattern, there are more scenarios where patterns need forking and the ones delegating to other patterns are mostly not a good fit for an AbstractDelegatePattern (e.g. RandomPattern) and might also already extend other classes (e.g. AbstractExtentPattern, do we need to fork them?).

Let me know what you think.

[SirYwell]

This might also be relevant for #2626, I'm just not sure what to expect from that pattern in a multi-threaded setting

[dordsor21]

Are there definitely no further instances where pattern might not necessarily get forked here?

[SirYwell]

Are there definitely no further instances where pattern might not necessarily get forked here?

I'll have to go through the WE patterns again, it seems there are a few more

[SirYwell]

Went through the impls again, should be all now hopefully.

[dordsor21]

Is there much of a point in having the new interface? If a new pattern that would use it is created then either we remember the interface or we don't (same chances as overriding the fork method tbh)

[SirYwell]

I thought about forking some of the patterns only if the inner patterns need to be forked, in which case it was somewhat useful as a marker interface, but I decided against the additional checking overhead, so I guess it can be removed again.

[dordsor21]

Should probably look at having the origin be toImmutable()ised when it's set (for this and any other patterns)

[SirYwell]

That would otherwise already cause bugs I think? But yeah, that might make sense.

[dordsor21]

Possibly, but can't be too careful aha