Rob:

I am not a python user but I would like to offer some points you might still find of some value.

FWIW, I have been using the FLTK lock mechanism now for a while and I find it satisfactory and reliable. I think as the core FLTK developers have noted in the past, though, without care, one can easily wind up serializing everything anyway, where effectively only a single thread is actually running at any point in time -- in which case, that could negate the point of the MT-exercise (if that matters to you). Another concern is making sure to put a lock in all the places that need it.

However, I have also been using a different scheme to get around the "GUI calls only in the main thread" issue that is a sort of "graphics server" approach. This relies on an intercommunicating pair of processes (parent-child in my application), where one process is the "GUI server", which implements the interactive GUI and makes all the FLTK calls, plus occasionally checks for incoming "commands" from the other process (and might enqueue them), or otherwise publishes data from the GUI to it. Not ideal for "real time", but it isn't as bad as some might think in terms of performance, at least on Linux where I do it. And for me, it's not that much worse than a locks-based approach, assuming efficient IPC between the processes. And proper GUI isolation for FLTK -- without so many worries as in the locks-based approach (like, maybe trying to do something if-y while being deep in callbacks) -- is the win for me.

In your situation, perhaps one process would be the FLTK GUI server while the other process would be the python thingie.

But note all my experience using these approaches with FLTK is only on Linux w/ C++.