Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removed .Count and used methods inside DynamicUpdateField to loop over #591

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

matanshukry
Copy link

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.

data.
Currently the sync method is lock, but that can be changed easily now
@Fabi
Copy link
Contributor

Fabi commented Mar 6, 2021

ConcurrentBag and/or BlockingCollection are your best friends.

@matanshukry
Copy link
Author

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
Copy link
Member

Shauren commented Mar 6, 2021

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
Copy link
Author

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
Copy link
Member

Shauren commented Mar 7, 2021

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

@guldo77
Copy link

guldo77 commented Aug 20, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants