Re: Problem with FXThread and begin/endWaitCursor()
Jeroen van der Zijp <[email protected]>
| Newsgroups | gmane.comp.lib.fox-toolkit.user |
|---|---|
| Organization | FOX Toolkit |
| Message-ID | <[email protected]> |
On Wed, 18 Jan 2023 21:46:47 +0000 <[email protected]> wrote: > Hi Jeroen, > > > I'm trying to understand a platform difference in our FOX based UI: We have a main FOX thread for the graphic interface, and occasionally we use an extra FXThread for loading files. Before starting the extra thread we call getApp()->beginWaitCursor() and after getApp()->endWaitCursor(), but always within the main thread of the FXApp. When I change the code so that getApp()->endWaitCursor() is called from within the extra FXThread instead of the main trhead, it works fine on Windows works but on Linux it crashes (X Fatal error) or simply freezes with a black screen. Do you have an idea what the problem could be and why it only shows up on Linux? > Neither Windows nor Linux can safely access the GUI from more than two threads. The underlying system APIs are different, and thus you can get lucky on one system and not on the other, or vice versa. Moreover, on Windows, only the thread that created the GUI can receive events, so this is an additional limitation. We recommend using worker threads only for non-GUI work; the worker thread can interact with the GUI thread via so-called FXMessageChannel. An FXMessageChannel can be used for a worker thread to send messages to the GUI thread, and have the handler of the message execute in the contect of the GUI thread. Behind the scenes, FXMessageChannel created a waitable object that the GUI thread adds to its list of watched file descriptors [it is already watching the user-interface [mouse, keyboard, etc]. Thus, when GUI thread wakes from its system call, it'll dispatch to handle not only GUI events but also activity from the worker thread. An internally created pipe functions as the buffer between worker thread and GUI thread. The GUI thread reads the message from this pipe, and then calls the designated routine with the message data read from the pipe. Thus, worker thread and GUI thread work asynchronously, Hope this helps. -- JVZ