Removed .Count and used methods inside DynamicUpdateField to loop over

[matanshukry]

Removed .Count and used methods inside DynamicUpdateField to loop over

Solves #590

Note:
While this implementation uses lock, the major thing is the refactor part of it where the implementation now lives in DynamicUpdateField class rather than outside of it, and can easily be changed.

[Fabi]

ConcurrentBag and/or BlockingCollection are your best friends.

[matanshukry]

ConcurrentBag and/or BlockingCollection are your best friends.

Like I wrote in the note, the implementation isn't really important.
I'm not familiar enough with the data to decide which method to use.

If thread A starts filling the values, and then threads B resizes it, should thread A still continue and fill the values?
What if the size doesn't fit? And even if it still fits - is the data thread A has is still relevant, even though the size now isn't? which one should override? ...

[Shauren]

Not only thread A still needs to continue reading as many items from packets as it originally intended, older packets must not overwrite stored values from new packets (important for sql output)

[matanshukry]

I'm assuming new packets can overwrite old packets (and should, otherwise their storage shouldn't be shared).

assuming we can have a "system" where new packets can overwrite data written by old packets, even in the middle of writing, what do we actually want to happen to the old packet?

• Don't let new packet stop you. Finish first, then let new packet start writing & resizing.
• Store a copy of the object with our own data and use that
• Wait until the new packet finished overwriting the data and then use the new data
• other?

@Shauren

[Shauren]

My idea was to make all properties on those classes nullable, have each packet operate on new object, store them in ConcurrentPriorityQueue then when time comes to output sql, merge them into single object

Anyway, no matter what we choose, it will require changes in the code generator for these parsers

[Guldan45]

Suppression de .Count et méthodes utilisées dans DynamicUpdateField pour boucler

Résout #590

Remarque : Bien que cette implémentation utilise le verrou, l'essentiel est la partie refactorisation de celle-ci où l'implémentation vit maintenant dans DynamicUpdateFieldla classe plutôt qu'en dehors de celle-ci, et peut facilement être modifiée.
packet wow is addon verified