Re: Initializing the GUI from a different thread

On 2022-02-25 09:48, Michael Behrisch wrote:
> Dear all,
> I have a question concerning setting up a multi threaded application.
> We have an application (https://github.com/eclipse/sumo) which works
> well if we initialize the FXApp and the main window from the main
> thread but it I use another thread to initialize the GUI it does not
> work any longer. The problem is that the application spawns more
> threads which communicate with the main window using an event queue
> (from the FXEX package:
> https://github.com/eclipse/sumo/blob/main/src/utils/foxtools/FXThreadEvent.h)
> but the main windows does not seem to get the signals any longer if we
> start it from the secondary thread. The problem occurs only on
> Windows, on Linux it works fine.
> 
> We are using FOX 1.6.57 and any idea is welcome.

I always *strongly* discourage letting any other thread than the
main GUI thread perform any GUI operations.

Reason is, on Windows, only the main thread can receive windows.

Actually, I think it may be worse: I think on Windows, if another
thread *creates* the window, its events only go to that thread.

[that is create(), not the C++ constructor; you might be able to
get away with having another thread call constructors, as long
as the main thread isn't simultaneously manipulating the widget
tree].

The FOX 1.7 uses FXMessageChannel, which allows [sort of]
asynchronous calls from worker-thread to execute in the context
of the main (GUI) thread.  It works by waking the main thread
from the event loop [where its blocked for inputs], and then
grabbing the message from a pipe that the worker thread has
left the message in.  It then handles the message and returns
to the main loop.

Bottom line, you can let worker-threads do the hard work [e.g.
manipulating databases, etc], and have the GUI thread perform
changes to the GUI, via FXMessageChannel.  It works reasonably
well, both Windows and Linux.

We use a pipe to pass the data. On Linux that's the only thing
needed, we can just add the pipe's FD in the watch list.  On
Windows, we create a semaphore and add its handle into the
watch list, because we can't watch a pipe-handle on Windows
[sadly!].  An Event would also be a possibility, but I think
a Semaphore is better as the thread may want to send multiple
messages and we'd like to have the handle remain signaled until
we've handled them all.






   -- JVZ