-
Notifications
You must be signed in to change notification settings - Fork 248
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
Proposed alternative to WorkerThread #1014
Labels
Open for Discussion
There are several possibilites to address the issue and anyone is invited for comments.
Comments
joachimmarder
added
the
Open for Discussion
There are several possibilites to address the issue and anyone is invited for comments.
label
Dec 30, 2020
Couldn't a threaded queue be used instead of posting windows messages or would this destroy backwards compatibility? |
IMO there are 2 clear goals that need to be fulfilled:
|
See my althernative in #1001 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Open for Discussion
There are several possibilites to address the issue and anyone is invited for comments.
After we found out in #1001 that essentially, we see no way for proper synchronization of
WorkerThread
, here's an idea of how validation of the positional cache (i.e. whatDoValidateCache()
currently does) could be done in the main thread without blocking it too much and therefore get rid ofWorkerThread
and it's problems completely:The general idea is to validate the cache in smaller chunks and not in one go. Each chunk could be started by posting a window message and when the message is handled, a new message for the next chunk is posted again, but only if validation has not been cancelled.
That way the validation would not be blocking, so the tree does feel responsive. It avoids the fundamental problem of a thread walking the nodes even though the tree node structure is not thread-safe. A possible disadvantage is the necessity to have a window handle for posting the window messages, but as this originally was also done for
WorkerThread
, this doesn't seem like a big problem.This change could also have the potential to improve the following things:
This is definitely a non-trivial change and quite a bit work. Ideally before changing anything, a set of tests should be developed that the new implementation can be checked against.
The text was updated successfully, but these errors were encountered: