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

Tracking issue for proper memory management, dropping, and threading #140

Open
nia-e opened this issue Jun 20, 2023 · 0 comments
Open

Tracking issue for proper memory management, dropping, and threading #140

nia-e opened this issue Jun 20, 2023 · 0 comments
Labels
bug Something isn't working enhancement New feature or request help wanted Extra attention is needed meta Tracking other issues or pull requests question Further information is requested

Comments

@nia-e
Copy link
Collaborator

nia-e commented Jun 20, 2023

The situation

We need to figure out a way to destroy all LVGL primitives in a safe way and synchronise access across threads. The issue in detail was outlined in this excellent writeup and the following discussion, but to summarise the current state of affairs:

  • Obj types and all extensions thereof i.e. all widgets are never dropped;
  • There is no safe way to access and interact with LVGL primitives across threads;
  • Implementing all Obj types as reference-counted values, or placing access to LVGL overall behind a global lock, may have considerable performance downsides;
  • Edge cases exist where multiple Obj instances point to the same underlying LVGL lv_obj_t, and care must be taken with dropping these.

Unanswered questions

  • What is the actual performance penalty for placing the LVGL API behind a mutex or similar?
  • Can we realistically store a global "hit-list" of pointers and somehow handle dropping behind that?
  • Can we do the above without alloc and massive performance penalties?
  • If not, is it realistic to feature-gate some/all of this proposal without too much redundancy?
  • If also not, is it possible to create distinct threadable and/or auto-dropping types for widgets i.e. LvManaged<T>: Send + Sync where T: Widget?

To-do

  • Benchmark Arc<T>ing widget types and locking the LVGL API;
  • Write some tests for our ideal desired behaviour;
  • Try to implement the suggestions that turn out to be reasonable.

Relevant PRs/issues:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request help wanted Extra attention is needed meta Tracking other issues or pull requests question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants
@nia-e and others