[Mackamuir]

Adds a lock around RegisterVariantCollection so that parallel prototype loading can't corrupt KindData.UnfrozenVariants.

Exception has occurred: CLR/System.ArgumentNullException
An exception of type 'System.ArgumentNullException' occurred in System.Private.CoreLib.dll but was not handled in user code: 'Value cannot be null.'
   at System.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument)
   at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
   at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector, IEqualityComparer`1 comparer)
   at System.Collections.Frozen.FrozenDictionary.ToFrozenDictionary[TSource,TKey,TElement](IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector, IEqualityComparer`1 comparer)
   at Robust.Shared.Prototypes.PrototypeManager.KindData.Freeze() in path\RobustToolbox\Robust.Shared\Prototypes\PrototypeManager.cs:line 1247
   at Robust.Shared.Prototypes.PrototypeManager.Freeze(IEnumerable`1 kinds) in path\RobustToolbox\Robust.Shared\Prototypes\PrototypeManager.cs:line 534
   at Robust.Shared.Prototypes.PrototypeManager.InstantiatePrototypes(KindData[] kinds, ValueTuple`4[] results, Channel`1 hooks) in path\RobustToolbox\Robust.Shared\Prototypes\PrototypeManager.cs:line 647
   at Robust.Shared.Prototypes.PrototypeManager.<>c__DisplayClass52_0.<InstantiateKinds>b__2() in path\RobustToolbox\Robust.Shared\Prototypes\PrototypeManager.cs:line 605
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)

RobustToolbox/Robust.Shared/Prototypes/PrototypeManager.cs

Lines 1253 to 1258 in a80d4d0

	// Freeze prototype variants associated with this kind
	if (UnfrozenVariants != null)
	{
	Variants = UnfrozenVariants.ToFrozenDictionary(kvp => kvp.Key, kvp => (IReadOnlyList<string>)kvp.Value);
	UnfrozenVariants = null;
	}

The issue is with this dict getting a null key, which it can't have, so thats bad.

Resolves #7199

Was a race condition before, but obviously if you run a million races it will hit eventually.

[metalgearsloth]

This looks pretty suss as any number of methods above it will explode without thread-safety?

[Mackamuir]

This looks pretty suss as any number of methods above it will explode without thread-safety?

Doubt it, each worker only edits node from the file it parsed, kindData is shared and unfrozenVariants is the only shared thing extractMapping writes to.

Honestly the chances of this happening are pretty low anyways, I was more curious and wanted to look into it. will just close and if it comes up again later for whatever reason someone can see here.

[Mackamuir]

Reopening this, since it's an issue

[metalgearsloth]

Also needs release note.

[DrSmugleaf]

Might be better to use a concurrent dictionary for this, at least from my experience in serialization code they are faster
Either way note below if you choose not to

[Mackamuir]

Might be better to use a concurrent dictionary for this, at least from my experience in serialization code they are faster Either way note below if you choose not to

Not sure if concurrent would be faster after initialization and freezing are included. If you want I can spend some time trying to get some benchmarks.

Would also mean making the initalization support threading but w/e

[DrSmugleaf]

Might be better to use a concurrent dictionary for this, at least from my experience in serialization code they are faster Either way note below if you choose not to

Not sure if concurrent would be faster after initialization and freezing are included. If you want I can spend some time trying to get some benchmarks.

Would also mean making the initalization support threading but w/e

Probably fine to leave it be, either way it will come up in a future profile if it's an issue