multithreading - What does it mean to "lock" an app's UI thread?

Question

I'm using the flkt-rs crate to design a GUI. I was wondering what it means to "lock" the UI thread of my application. Does this mean that no CPU is being allocated to that thread? Why would you want to lock the UI thread? When would then want to unlock it?

Additionally I see that that the fltk::app::lock() function returns a result, which implies that there might be some issues associated with using it. What could prevent you from succesfully locking the UI thread?

lock function from the fltk-rs docs:

pub fn lock() -> Result<(), FltkError>

question from:https://stackoverflow.com/questions/65944979/what-does-it-mean-to-lock-an-apps-ui-thread

Answer 1

From the FLTK C++ documentation:

In a multithreaded program, drawing of widgets (in the main() thread) happens asynchronously to widgets being updated by worker threads, so no drawing can occur safely whilst a widget is being modified (and no widget should be modified whilst drawing is in progress).

FLTK supports multithreaded applications using a locking mechanism internally. This allows a worker thread to lock the rendering context, preventing any drawing from taking place, whilst it changes the value of its widget.

So you wouldn't lock the UI for long periods of time; just enough time to safely update the state of a widget, and then unlock it again.

What could prevent you from succesfully locking the UI thread?

This may be addressed by the next paragraph in the same documentation:

To incorporate the locking mechanism in the library, FLTK must be compiled with –enable-threads set during the configure process. IDE-based versions of FLTK are automatically compiled with the locking mechanism incorporated if possible. Since version 1.3, the configure script that builds the FLTK library also sets –enable-threads by default.

If the application is compiled to be single-threaded then locking the main thread would lock the entire application permanently. It doesn't explicitly say it, but it seems reasonable that there would be a FailedToLock error in this situation.

This kind of API doesn't feel very "Rusty" and it's likely like this because the fltk-rs crate is a thin wrapper around the C++ library.