Tracking issue for proper memory management, dropping, and threading

[nia-e]

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:

• #110
• #111
• #141
• #143
• #144