gtk2hs and runghc - Haskell-Cafe - Haskell.org

newer
Status of GHC as a Cross Compiler

gtk2hs and runghc

older
Ctrl-C handling in Haskell with...

Günther Schmidt

22 Sep 2009 22 Sep '09

11:31 a.m.

Hi, I'm trying to test some gtk2hs gui code without compiling it first, just by using runghc. Gtk2hs then complains about running in a multithreaded ghc, ie. one with several "real" OS threads. Is it possible to start runghc single-threaded? Günther

Reply

Sign in to reply online Use email software

Show replies by date

Brandon S. Allbery KF8NH

22 Sep 22 Sep

5:08 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 22, 2009, at 11:31 , Günther Schmidt wrote:

Gtk2hs then complains about running in a multithreaded ghc, ie. one with several "real" OS threads. Is it possible to start runghc single-threaded?

No, but you can unsafeInitGUIForThreadedRTS. - -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) iEYEARECAAYFAkq5PNcACgkQIn7hlCsL25UbYQCfSTz6RgOOB2v2x5aWQl2wTqQ0 5/sAnipoGEOCHn0zXfsx9H3N4ggp/7aJ =Czq6 -----END PGP SIGNATURE-----

Reply

Sign in to reply online Use email software

Duncan Coutts

23 Sep 23 Sep

1:29 p.m.

On Tue, 2009-09-22 at 17:08 -0400, Brandon S. Allbery KF8NH wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sep 22, 2009, at 11:31 , Günther Schmidt wrote:

...
Gtk2hs then complains about running in a multithreaded ghc, ie. one with several "real" OS threads. Is it possible to start runghc single-threaded?

No, but you can unsafeInitGUIForThreadedRTS.

If you observe the foot-shooting restrictions (of which the easiest is to not use forkIO). Duncan

Reply

Sign in to reply online Use email software

Günther Schmidt

2:24 p.m.

Am 23.09.2009, 19:29 Uhr, schrieb Duncan Coutts :

On Tue, 2009-09-22 at 17:08 -0400, Brandon S. Allbery KF8NH wrote:

...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sep 22, 2009, at 11:31 , Günther Schmidt wrote:

...
Gtk2hs then complains about running in a multithreaded ghc, ie. one with several "real" OS threads. Is it possible to start runghc single-threaded?

No, but you can unsafeInitGUIForThreadedRTS.

If you observe the foot-shooting restrictions (of which the easiest is to not use forkIO).

Duncan

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. It seems to work once the app is compiled, but running the code in either ghci or with runghc it crashes. Günther

Reply

Sign in to reply online Use email software

Ross Mellgren

3:52 p.m.

Well, keep in mind forkIO *might* be a different OS thread (unless it's bound, IIRC), depending on the number of workers (with -Nx) and so on. -Ross On Sep 23, 2009, at 2:24 PM, Günther Schmidt wrote:

Am 23.09.2009, 19:29 Uhr, schrieb Duncan Coutts
...
:

...
On Tue, 2009-09-22 at 17:08 -0400, Brandon S. Allbery KF8NH wrote:

...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sep 22, 2009, at 11:31 , Günther Schmidt wrote:

...
Gtk2hs then complains about running in a multithreaded ghc, ie. one with several "real" OS threads. Is it possible to start runghc single-threaded?

No, but you can unsafeInitGUIForThreadedRTS.

If you observe the foot-shooting restrictions (of which the easiest is to not use forkIO).

Duncan

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.

It seems to work once the app is compiled, but running the code in either ghci or with runghc it crashes.

Günther

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply

Sign in to reply online Use email software

Duncan Coutts

4:38 p.m.

On Wed, 2009-09-23 at 15:52 -0400, Ross Mellgren wrote:

Well, keep in mind forkIO *might* be a different OS thread

Yes.

(unless it's bound, IIRC)

In which case it's guaranteed to be on a different OS thread..

depending on the number of workers (with -Nx) and so on.

The number of capabilities is mostly unrelated. All these problems will happen with -N1 and -N2. Essentially each capability has a pool of OS threads. Only one of these OS threads runs Haskell code at once, but which one it is at any particular time is not defined. The trick that postGUI uses is to arrange for a foreign callback (from C into Haskell) on the OS thread running the GUI. This creates a Haskell thread that runs on that OS thread until the callback returns. Duncan

Reply

Sign in to reply online Use email software

Duncan Coutts

4:12 p.m.

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

Reply

Sign in to reply online Use email software

Günther Schmidt

6:10 p.m.

Hi Duncan, so ... I have a green light to call gtk from within a forkIO thread for as long as I make sure that the rts is single threaded? BTW: I was already strongly put off using unsafeInitGUIwForThreadedRTS but thanks for the warning. Thus my back to my original question: Can I start either ghci or runghc with a single-threaded rts so I don't have to compile the app every time I want to check my really trick GUI code? Günther

Reply

Sign in to reply online Use email software

Duncan Coutts

24 Sep 24 Sep

9:17 a.m.

On Thu, 2009-09-24 at 00:10 +0200, Günther Schmidt wrote:

Hi Duncan,

so ... I have a green light to call gtk from within a forkIO thread for as long as I make sure that the rts is single threaded?

Yes and that works very nicely (with the cooperative scheduling trick described in the gtk2hs FAQ).

BTW: I was already strongly put off using unsafeInitGUIwForThreadedRTS but thanks for the warning.

Thus my back to my original question: Can I start either ghci or runghc with a single-threaded rts so I don't have to compile the app every time I want to check my really trick GUI code?

No. The ghc binary itself (ghc, runghc, ghci) is linked using the threaded runtime system. That's a link-time choice, there's no way to turn it on/off at the command line (that might change in future with shared libs). Duncan

Reply

Sign in to reply online Use email software

5736

Age (days ago)

5738

Last active (days ago)

Download

8 comments

4 participants

tags

participants (4)

Brandon S. Allbery KF8NH
Duncan Coutts
Günther Schmidt
Ross Mellgren