[PB5.22LTS] MessageRequester and Threads

[manu]

Hello!
I'm trying to port an application from Windows to Linux. I'm having trouble with threads, though I enabled ThreadSafe compiling.
Here is a small example code:

Code: Select all

Procedure About(*dummy)
  MessageRequester("Requester","Click ok")
EndProcedure

OpenWindow(0, 0, 0, 220, 70, "Example", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
ButtonGadget(1, 10, 10, 200, 20, "Click me")
TextGadget(2, 10, 40, 200,20,"")
date_old=Date()
Repeat
  Event = WaitWindowEvent(100)
  If Event=#PB_Event_Gadget And EventGadget()=1
    CreateThread(@About(),0)
  EndIf
  date_new=Date()
  If date_old<>date_new:date_old=date_new:SetGadgetText(2,FormatDate("%hh:%ii:%ss",date_new)):EndIf
Until Event = #PB_Event_CloseWindow

I have added the textgadget just make visible that the main event loop is still running.
Using windows, the program runs fine.
With linux (tested with 32bit), the program crashes or hangs when you click the button.
Am I missing something here? Is MessageRequester not thread safe?
Any simple workarounds are also welcome.
I know I could just not use MessageRequester but create a new window and handle everything from the main thread, but that is somewhat more complicated than this simple solution that works with windows. Ideally, it should work the same with linux.

--manu

[idle]

All windows need to be handled in the main thread it's a limitation of GTK
but you can thread procedures and set window and gadget states from them

[luis]

GTK it's actually thread-aware but not thread-safe, not without help from the programmer, at least this is the impression I've got.

To have a taste of what "help from the programmer" would mean try this:

Code: Select all

Procedure About(*dummy)
 gdk_threads_enter_()
 MessageRequester("Requester","Click ok")
 gdk_threads_leave_()  
EndProcedure

I'm not saying it's the proper way to do it, it's just an example of the fact you could put GTK calls in different threads, I didn't really look into it too much.
And I wouldn't use it in a PB program. All is already wrapped by PB in way we don't really know, especially the main loop etc.

I would rethink the program logic, it's less risky.

[auser]

Using windows, the program runs fine.

I'm a linux-fanboy and used linux based OS for years almost exclusive at my own stuff. However that "windows processing have to be in the mainthread crap" (in the 21st century with multicore processors and GPUs that do lots of parallel processing and own gigabytes of memory) seems solved better in the MS-Windows world than in that GNU/Linux and BSD based OS GUIs (GTK, QT, ...). If you would run some mainthread that _just start_ various threads with some sensitive parameters like connection-info or password and that should give user possibility to monitor some infos at it's lifetime or just show some progressbar (and no further data is required forward or backward to the mainthread after start) you still have to report backwards and forwards to a spagetti-mainthread just for that windows stuff (even if the major work is done modular somewhere different). I see no advantage in forcing a programmer to keep windows-functions in the mainthread (or in a single-thread). Previous releases of PB allowed multi Openwindows() in different threads (in MS-Windows) but this changed since other GUIs of other OS does not like that. It's still possible to use it that way if you disable the debugger in windows but same code on linux would crash and it seems the MessageRequester is causing similar issues.

[Fred]

Unfortunately, you can't use a requester in a thread in linux or OS X.

https://developer.gnome.org/gdk3/stable ... reads.html

As you can see, even if it was partly supported before starting from GTK 3.6 it's forbidden:

gdk_threads_enter has been deprecated since version 3.6 and should not be used in newly-written code. All GDK and GTK+ calls should be made from the main thread

[auser]

gdk_threads_enter has been deprecated since version 3.6 and should not be used in newly-written code. All GDK and GTK+ calls should be made from the main thread

In my opinion it's a shame and a step backwards regarding freedom and modular design. GUI is just one part of a software that have to be done and is not privileged compared to others. You are forced to micro-management the GUI back to the mainthread which picks out a part of module that could stay encapsulated on it's own (regarding the data it's processing) into a spagetti-mainthread (that get data back that are just required to change some windows but not because the main-thread itself needs it anymore). At least linux would remain my very favorite server-OS.

[luis]

Oh good to know, didn't know it was deprecated.
Another reason to forget about it beyond the simple experiment above.

[Fred]

gdk_threads_enter has been deprecated since version 3.6 and should not be used in newly-written code. All GDK and GTK+ calls should be made from the main thread

In my opinion it's a shame and a step backwards regarding freedom and modular design. GUI is just one part of a software that have to be done and is not privileged compared to others. You are forced to micro-management the GUI back to the mainthread which picks out a part of module that could stay encapsulated on it's own (regarding the data it's processing) into a spagetti-mainthread (that get data back that are just required to change some windows but not because the main-thread itself needs it anymore). At least linux would remain my very favorite server-OS.

Notes than OS X also has the same limitation. Only Windows allows that correctly, and I agree it would be better if other OS had follow the Windows way. Anyway, GTK is opensource, so you can contribute to make it better if you to

[manu]

Thanks for all your quick replies. Too bad that it's not fixable.

I have to change my program accordingly.

The gdk_threads_enter_()/_leave() stuff wouldn't have helped I guess because it would have stopped the mainloop from running also.

Maybe a small hint could be added to the help text of MessageRequester() just like the hint I found in OpenWindow() help stating that you shouldn't open a window in a thread.

[luis]

The gdk_threads_enter_()/_leave() stuff wouldn't have helped I guess because it would have stopped the mainloop from running also.

Did you try it ? Because using your example the messagebox is shown, the main loop is looping and there is no crash, at least on my PC.
Else I wouldn't have post it. In a more complex scenario is not applicable anyway mixing it with PB commands for the reasons above unless one goes full GTK and doesn't use PB gui commands at all. I still think it should have been possible to make all work in that case.

But all this is ignoring the fact is deprecated, so there is no much point in it going forward

[manu]

I tried my example with your gdk_threads_enter_()/_leave() additions.
It does not crash but it is far away from working properly. On my linux machine, it takes a few seconds (!) for the Requester to appear properly and then yes, the clock starts running but the program is very unreactive.
And the Requester is not "modal" then any more, so the main window can be clicked. If you click on "click me" again, you get another Requester (again, very unreactive). If you click on "OK" of the first requester, the second requester will close, not the first?!
So all in all purebasic is not prepared for me to use gdk_threads_enter_()/_leave(), it makes things go worse and it's deprecated, so I don't think it's a possible workaround...

[auser]

I wonder how wine (acronym "Wine Is Not an Emulator") handles that issue because running the example which was posted on the top does not crash the program if it was compiled on windows and started on linux via "wine test.exe" and even the timer continues to run (so it seems to be a different thread that shows the messagerequester).

[ts-soft]

Problems with Threads do not become apparent immediately, they come after one or only after thousands of tests!
You have to go as documented, tests doesn't help.

[luis]

Never said it was the proper way to do it and that you can get great results using it with PB, I said the opposite in fact.

But the points I was making were:

1) the main loop wasn't stopped (you said you were supposing it would be stopped)
2) it was not crashing (like the original code)

All the other problems you are experiencing are because it's running in multithreading and so you can see the problems you were not able to see with you original code because it was just crashing. They are not a consequence of gdk_threads_enter_() / _leave().

So all in all purebasic is not prepared for me to use gdk_threads_enter_()/_leave(), it makes things go worse

Yes. At least if used mixing it with the PB gui. It can work IMO if you go full GTK.

and it's deprecated, so I don't think it's a possible workaround...

And we all agree here.

Bye !

@auser

It's not surprising it works under wine.

... vanishing

[auser]

It's not surprising it works under wine.

I don't wonder if it works but how it works via wine especially if the major linux-guis lacks that behavior. I even tried to play a bit with fork_() and so on but got some strange results.