On Wed, 2009-09-23 at 20:24 +0200, Günther Schmidt wrote: > >> No, but you can unsafeInitGUIForThreadedRTS. > > > > If you observe the foot-shooting restrictions (of which the easiest is > > to not use forkIO). > >
> And exactly herein lies the problem :) > > I've seen your response to the recent post about gui state, in which you > mention your own prefered solution to the problem, ie. that you "post" > your state to a channel which is read in a thread. > > I'm doing the same thing, but I'm also "calling" gui code from within that > thread. > I figured since the thread itself isn't a separate OS thread it > shouldn't be a problem. Stop! You are confused about the relationship between Haskell threads and OS threads. By default you have _no_ control over which OS thread your Haskell threads run on. Using forkIO provides no promises at all about that. Using forkOS provides the opposite guarantee to the one you want. There is no API to launch a Haskell thread and guarantee that runs on the same OS thread as some existing Haskell thread. (One way is to use the single-threaded rts) The documentation for unsafeInitGUIForThreadedRTS states: If you want to use Gtk2Hs and the threaded RTS then it is your obligation to ensure that all calls to Gtk+ happen on a single OS thread. If you want to make calls to Gtk2Hs functions from a Haskell thread other than the one that calls this functions and mainGUI then you will have to 'post' your GUI actions to the main GUI thread. You can do this using postGUISync or postGUIAsync. The postGUI actions do some magic so that your IO actions are run on the same OS thread as the GUI is running on. > It seems to work once the app is compiled, but running the code in either > ghci or with runghc it crashes. Right, because when you compile it you are using the single threaded rts but if you linked using -threaded or if you use ghci or runghc then you are using the threaded rts. There are two solutions: 1. use the single threaded rts 2. annotate all sequences of GUI calls with postGUISync or postGUIAsync so that they get run in the GUI thread and not some random thread. The first is obviously much easier. Only go with the second if for some reason you actually need the -threaded rts. There is no claim that the second option is a good GUI programming model. The Gtk2Hs developers added the possibility of running on the threaded rts due to popular demand but the intention of the reallyLongNamedFunction unsafeInitGUIForThreadedRTS is to make you stop and think about what you are doing :-). Perhaps we should make it even more so, like unsafeInitGUIIHaveReadTheDocsAndIAmSureIAmNotGoingToShootMyselfInTheFoot Duncan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe