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

Render from main thread rather than input plugin thread by default #19

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

hartwork
Copy link
Owner

@hartwork hartwork commented Mar 1, 2023

Motivation:

  • Some vis plugins turned out to not be prepared to receive window messages from multiple threads concurrently.
  • When then input plugin thread drives the vis plugin, visdriver has no control over vis plugin render rate.

Assumptions:

  • Vis plugins want to present the latest data available. The second latest data may be better than no data, but the latest data should win over older data wherever possible, forwarding all data is not the goal.
  • Allowing to both read and write a block of vis data at the same time could make the vis plugin render inconsistent data, so that should be avoided. Access to each bucket's state needs to be atomic.
  • There is at most one reader (copying to the vis plugin) and at most one writer (copying from the input plugin) at any point in time.
  • If one of reader and writer are ever way slower than the other part, two buckets will not be enough. E.g. if bucket 0 is locked by the reader and the writer just finished writing to bucket 1 but hits again while the reader is still blocking bucket 1 the writer would then need to (a) not write the most recent data at all or (b) overwrite bucket 2 and force the reader to serve data from bucket 1 again that is less recent than ideal.
  • Use of pessimistic locking would not be ideal in the input plugin thread.

Motivation:
- Some vis plugins turned out to not be prepared to receive window
  messages from multiple threads concurrently.
- When then input plugin thread drives the vis plugin, visdriver has
  no control over vis plugin render rate.

Assumptions:
- Vis plugins want to present the latest data available.
  The second latest data may be better than no data,
  but the latest data should win over older data wherever possible,
  forwarding all data is not the goal.
- Allowing to both read and write a block of vis data at the same time
  could make the vis plugin render inconsistent data, so that should
  be avoided.  Access to each bucket's state needs to be atomic.
- There is at most one reader (copying to the vis plugin)
  and at most one writer (copying from the input plugin) at any
  point in time.
- If one of reader and writer are ever way slower than the other part,
  two buckets will not be enough. E.g. if bucket 0 is locked
  by the reader and the writer just finished writing to bucket 1
  but hits again while the reader is still blocking bucket 1
  the writer would then need to (a) not write the most recent data
  at all or (b) overwrite bucket 2 and force the reader to serve
  data from bucket 1 again that is less recent than ideal.
- Use of pessimistic locking would not be ideal in the input plugin thread.
@hartwork hartwork added the enhancement New feature or request label Mar 1, 2023
@hartwork hartwork marked this pull request as draft May 5, 2024 18:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant