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:


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!


---------- Původní zpráva ----------
Datum: 5. 9. 2012
Předmět: Re: [Gtk2hs-users] New threaded GUI tutorial


> 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
forkOS (initGUI >> {- setup code -} >> mainGUI)

it should almost always be possible to write

main = do
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.


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
Gtk2hs-users mailing list