From: <tim...@se...> - 2012-09-04 21:26:32
|
Hey, I just uploaded this http://www.haskell.org/haskellwiki/Gtk2Hs/Tutorials/ ThreadedGUIs after a long time user claimed to me that threaded GUI was somehow not supported. Hopefully I covered all the main points. And hopefully there aren't too many horrible errors.. Timothy |
From: <wag...@se...> - 2012-09-04 22:18:12
|
Quoting tim...@se...: > Hey, > I just uploaded this http://www.haskell.org/haskellwiki/Gtk2Hs/Tutorials/ > ThreadedGUIs after a long time user claimed to me that threaded GUI was > somehow not supported. Hopefully I covered all the main points. And > hopefully there aren't too many horrible errors.. > > Timothy You might also like my own tutorial (which includes a bit more discussion of Gtk and GHC internals): http://dmwit.com/gtk2hs You claim GTK is single-threaded; this is not true. GTK is thread-agnostic on sane operating systems. However, it is true that apps with cross-platform use as a goal should treat GTK as if it were single-threaded: on Windows, calls bottom out at the Win32 API, which uses thread-local state. Indeed, for this reason, I *think* your advice to fork mainGUI is bad -- you want mainGUI to have access to the thread-local state set up during program initialization. (Actually not 100% sure about that one.) Also, your suggestion to use unsafeInitGUIForThreadedRTS "to avoid deprecation warnings" is backwards: unsafeInitGUI is the deprecated one; initGUI now just Does The Right Thing with respect to the threaded and non-threaded runtimes. ~d |
From: <wag...@se...> - 2012-09-04 22:36:14
|
Quoting wag...@se...: > uses thread-local state. Indeed, for this reason, I *think* your > advice to fork mainGUI is bad -- you want mainGUI to have access to > the thread-local state set up during program initialization. (Actually To be more clear about what I mean here: I think if you plan on running the GUI on another thread, forkOS is the right way to do it; however, you should also run all the GUI setup on that other thread, too. So, instead of main = do initGUI {- create some widgets -} forkOS mainGUI {- do other processing -} it should look like main = do forkOS $ do initGUI {- create some widgets -} mainGUI {- do some other processing -} I'd love to be proven wrong about this, and would expect the proof to be of the form: "Actually, it turns out that none of the setup functions I'm interested in call into the Win32 API. They just set up Gtk-internal data structures without informing Windows of anything.". That seems pretty plausible; but possibly a dangerous invariant to rely on maintaining. Cheers, ~d |
From: <tim...@se...> - 2012-09-04 22:44:13
|
Oh, I wish I had known about your tutorial a year ago! I will link to it from the wiki. And I will also remove the link to this http://projects. haskell.org/gtk2hs/archives/2005/07/24/writing-multi-threaded-guis/#more-38 as it's out of date and misleading(If the web-master for that site is on this list, they should put a big yellow disclaimer on that). About using forkOS. I have used the method I described, and so far not been able to link any problems to it. It's not a problem though, if it turns out that there are problems with it, to do "initGUI >> forkOS mainGUI" Being able to use an exitMVar is a must however. You remember what I said about waiting for files to save before exiting. Of course we could have a special exitWaitingForFilesToChange function. But imagine what bits of state that function needs access to. It causes a horrible spaggetiing of state to not be able to use the exit MVar method. ---------- Původní zpráva ---------- Od: wag...@se... Datum: 5. 9. 2012 Předmět: Re: [Gtk2hs-users] New threaded GUI tutorial "Quoting tim...@se...: > Hey, > I just uploaded this http://www.haskell.org/haskellwiki/Gtk2Hs/Tutorials/ (http://www.haskell.org/haskellwiki/Gtk2Hs/Tutorials/) > ThreadedGUIs after a long time user claimed to me that threaded GUI was > somehow not supported. Hopefully I covered all the main points. And > hopefully there aren't too many horrible errors.. > > Timothy You might also like my own tutorial (which includes a bit more discussion of Gtk and GHC internals): http://dmwit.com/gtk2hs(http://dmwit.com/gtk2hs) You claim GTK is single-threaded; this is not true. GTK is thread-agnostic on sane operating systems. However, it is true that apps with cross-platform use as a goal should treat GTK as if it were single-threaded: on Windows, calls bottom out at the Win32 API, which uses thread-local state. Indeed, for this reason, I *think* your advice to fork mainGUI is bad -- you want mainGUI to have access to the thread-local state set up during program initialization. (Actually not 100% sure about that one.) Also, your suggestion to use unsafeInitGUIForThreadedRTS "to avoid deprecation warnings" is backwards: unsafeInitGUI is the deprecated one; initGUI now just Does The Right Thing with respect to the threaded and non-threaded runtimes. ~d ---------------------------------------------------------------------------- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ (http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/) _______________________________________________ Gtk2hs-users mailing list Gtk...@li... https://lists.sourceforge.net/lists/listinfo/gtk2hs-users (https://lists.sourceforge.net/lists/listinfo/gtk2hs-users)" |
From: <wag...@se...> - 2012-09-04 23:14:11
|
Quoting tim...@se...: > link any problems to it. It's not a problem though, if it turns out that > there are problems with it, to do "initGUI >> forkOS mainGUI" "initGUI >> forkOS mainGUI" is no different from "do { initGUI; forkOS mainGUI }". As outlined in my other email (sorry if yours is crossing paths with it -- I only realized after I wrote it how ambiguous I was being) the safe transformation is "forkOS (initGUI >> mainGUI)". > Being able to use an exitMVar is a must however. You remember what I said > about waiting for files to save before exiting. Of course we could have a > special exitWaitingForFilesToChange function. But imagine what bits of > state that function needs access to. It causes a horrible spaggetiing of > state to not be able to use the exit MVar method. I'm not sure I understand your claimed architecture, but it should very rarely be *necessary* to fork the GUI on another OS thread than main; instead of main = do foo forkOS (initGUI >> {- setup code -} >> mainGUI) bar it should almost always be possible to write main = do foo forkIO bar initGUI >> {- setup code -} >> mainGUI The "almost always" is only there in case you are also using some other library which also uses thread-local state, in which case you may wish to let it run on the main thread and give gtk a separate OS thread other than main. I think this situation is exceedingly rare. But I will again say that both of these are fine: there's nothing wrong with running Gtk functions on another thread as long as you know (and follow) the rules. The only technical difference to be aware of is that in the former, `bar` is on a bound thread and on the latter it is not; as long as you don't care whether `bar` is bound or not, the choice is aesthetic. ~d |
From: <tim...@se...> - 2012-09-04 23:23:45
|
Yes, I realized my error of writing (initGUI >> forkOS mainGUI) when I meant forkOS (initGUI>>mainGUI)... You end up doing everything after that inside a postGUIAsync. The reason why having the exit MVar in the "main" thread should be obvious, once you realize what happens when the GTK gui somehow crashes(It can happen even without bugs in your own program. Uncatchable resource errors ect.). You *still* want to save your work. So instead of having to create some special case for that like: mainGUI emergencySaveThatWeHopeDoesn'tGetRunButStillAddsComplexity we just always have an exit MVar sitting in our main thread keeping our program alive. Of course, in the case that I'm describing, even what I put on the wiki isn't enough to save you, because as soon as the GUI crashes we' ll get a blocked on MVar error. At least that's catchable though! Timothy ---------- Původní zpráva ---------- Od: wag...@se... Datum: 5. 9. 2012 Předmět: Re: [Gtk2hs-users] New threaded GUI tutorial "Quoting tim...@se...: > link any problems to it. It's not a problem though, if it turns out that > there are problems with it, to do "initGUI >> forkOS mainGUI" "initGUI >> forkOS mainGUI" is no different from "do { initGUI; forkOS mainGUI }". As outlined in my other email (sorry if yours is crossing paths with it -- I only realized after I wrote it how ambiguous I was being) the safe transformation is "forkOS (initGUI >> mainGUI)". > Being able to use an exitMVar is a must however. You remember what I said > about waiting for files to save before exiting. Of course we could have a > special exitWaitingForFilesToChange function. But imagine what bits of > state that function needs access to. It causes a horrible spaggetiing of > state to not be able to use the exit MVar method. I'm not sure I understand your claimed architecture, but it should very rarely be *necessary* to fork the GUI on another OS thread than main; instead of main = do foo forkOS (initGUI >> {- setup code -} >> mainGUI) bar it should almost always be possible to write main = do foo forkIO bar initGUI >> {- setup code -} >> mainGUI The "almost always" is only there in case you are also using some other library which also uses thread-local state, in which case you may wish to let it run on the main thread and give gtk a separate OS thread other than main. I think this situation is exceedingly rare. But I will again say that both of these are fine: there's nothing wrong with running Gtk functions on another thread as long as you know (and follow) the rules. The only technical difference to be aware of is that in the former, `bar` is on a bound thread and on the latter it is not; as long as you don't care whether `bar` is bound or not, the choice is aesthetic. ~d ---------------------------------------------------------------------------- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ (http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/) _______________________________________________ Gtk2hs-users mailing list Gtk...@li... https://lists.sourceforge.net/lists/listinfo/gtk2hs-users (https://lists.sourceforge.net/lists/listinfo/gtk2hs-users)" |