Re: Initializing the GUI from a different thread

Hi Michael,

Another question - do you use Python to spawn the threads (FxApp, 
FxMainWindow)?

I am asking (as you might already well aware) -  because Python 
multithreading is tricky.  It is not real multi-threading with 
concurrent running, but just switching different thread context so 
different threads executing sequentially.   See this: 
https://realpython.com/python-gil/

Best
Wuping

------ Original Message ------
From: "Wuping Xin" <[email protected]>
To: "Michael Behrisch" <[email protected]>; [email protected]
Cc: "FOX Users" <[email protected]>
Sent: 3/1/2022 8:19:19 AM
Subject: Re[2]: [Foxgui-users] Initializing the GUI from a different 
thread

>Hi Michael,
>
>Does the FxApp instance get created/initiated/run in the SAME thread as the MainWindow instance?  If they are created in different threads (different thread context), then it won't work (due to the fact that on Windows, each thread has its own message queue).
>
>Best
>Wuping
>
>------ Original Message ------
>From: "Michael Behrisch" <[email protected]>
>To: [email protected]; "Wuping Xin" <[email protected]>
>Cc: "FOX Users" <[email protected]>
>Sent: 3/1/2022 4:40:29 AM
>Subject: Re: [Foxgui-users] Initializing the GUI from a different thread
>
>>Hi Jeroen, hi Wuping Xin, hi all,
>>
>>Am 28.02.22 um 16:32 schrieb [email protected]:
>>>On 2022-02-28 09:14, Wuping Xin wrote:
>>>>FXApp.cpp, line 1432 (and several other places),  isn't this the
>>>>WndProc registration with the WndClass, as required by Win32 GUI
>>>>programming?
>>>>
>>>>   wndclass.lpfnWndProc=(WNDPROC) FXApp::wndproc;
>>>
>>>Absolutely!  This is the main window proc.  But its fed by
>>>the message queue [getNextEvent() grabs them from there].
>>>
>>>
>>>>And WndProc in turn, calls app->dispatchEvent, which propels the
>>>>message queue in the current thread context (i.e., the main thread).
>>>>
>>>>FXival CALLBACK FXApp::wndproc(FXID hwnd,FXuint iMsg,FXuval
>>>>wParam,FXival lParam){
>>>>   return app->dispatchEvent(hwnd,iMsg,wParam,lParam);
>>>>   }
>>>>
>>>>But of course, each thread has its own message queue that belongs to
>>>>its isolated thread context.   The UI thread spawned separately,
>>>>however, does not have message dispatching needed by the UI  -  all
>>>>messages would end up in a "black hole".
>>>
>>>Well, that's how windows is organized.  On Linux/Unix, the event queue
>>>does not belong to any particular thread and events are delivered to
>>>whomever pulls them from the queue. [just not do all threads at once,
>>>please!].
>>>
>>>The best we can do, in portable applications, is to have a single
>>>thread manage the GUI.  You can have as many worker threads as you
>>>want, however.  So its a division of labor issue.
>>
>>I have to admit I have a hard time following your discussion, so I just want to describe my problem in more detail.
>>
>>We already have python bindings for sumo called libsumo where the user can start the simulation and modify it from her python script the way she likes. Now we want to do the same thing with sumo-gui where the obvious thing to do (namely call app.run() when the user starts the sim) does not work because run() does not return until the app is finished and the second most obvious thing trying to move run() (and all the other GUI initialization stuff) to another thread seems not to work on Windows as well.
>>
>>So is this a FOX limitation which might get fixed in a future version?
>>Or is this in general not feasible on Windows (or would need a major rework of FOX) and we should simply start a separate GUI process and stick to doing things with interprocess communication here?
>>
>>Thanks for your advice,
>>Michael
>