- Glasgow-haskell-users

RE: [HOpenGL] HOpenGL and --enable-threaded-rts
by Simon Marlow 18 Jun '02

18 Jun '02

> Has anyone already thought about how to solve this problem? > I'm thinking about adding hooks to the RTS (in grabCapability, > releaseCapability and scheduleThread_) which would be used > for setting > up the correct thread-local state whenever Haskell execution > "switches" > to a different OS thread. Those hook routines would have to > be written > in C and would be platform-specific most of the time. It's not a nice > solution, but it's the only one I can think of at this time. > Unless someone comes up with a better idea _quickly_, I'll try it out > and then report how ugly it really is... :-) I can't see a nice solution to this problem - it really invalidates one of the key assumptions in the threaded implementation of the RTS, namely that it doesn't matter which OS thread we use to execute Haskell code. I suspect that a "safe" foreign import could be made to switch threads to the right OS thread before entering C land, but that's way too much overhead to impose on every single FFI call from Haskell. Yes, my guess is that this will probably have to be done by manipulating the thread-local state in the RTS - grab the current thread-local state whenever a call is made into Haskell, and whenever we run a Haskell thread we have to set the appropriate thread-local state. Perhaps it should be stored in the TSO and inherited by child threads too. The trouble is that there isn't a single object representing the whole thread-local state. Does OpenGL use pthread_getspecific() and pthread_setspecific() to access its thread-local state? Cheers, Simon

3 2

RE: SocketPrim Patch
by Simon Marlow 18 Jun '02

18 Jun '02

> Here's the patch to allow the setting of TTL in the IP header. > I can now send whatever value I like. Committed; thanks! Simon

1 0

SocketPrim Patch
by D.J.Steinitz 18 Jun '02

18 Jun '02

Simon, Here's the patch to allow the setting of TTL in the IP header. I can now send whatever value I like. Many thanks for all your help. Dominic. Index: SocketPrim.hsc =================================================================== RCS file: /cvs/fptools/hslibs/net/Attic/SocketPrim.hsc,v retrieving revision 1.12.2.5 diff -r1.12.2.5 SocketPrim.hsc 590a591,593 > #ifdef IP_TTL > | TimeToLive {- IP_TTL -} > #endif 621a625,627 > #ifdef IP_TTL > TimeToLive -> #const IPPROTO_IP > #endif 661a668,670 > #endif > #ifdef IP_TTL > TimeToLive -> #const IP_TTL

1 0

RE: HOpenGL and --enable-threaded-rts
by Simon Peyton-Jones 17 Jun '02

17 Jun '02

This is nasty. As I understand it, * GLUT assumes that the same OS thread executes some Haskell code, calls C, which calls back to Haskell. * Concurrent Haskell never lets this happen, for very good reason. The thread executing Haskell code is just an anonymous OS thread executing multiple Haskell threads. The good reason is this: if one designated OS thread must execute a particular bunch of Haskell code, what if that OS thread gets blocked doing I/O on behalf of some other Haskell thread? It's hard to say just which Haskell threads "belong" to that designated OS thread. The only thing I can think of is that the Haskell call-back thread somehow says that it can only be executed by the designated OS thread; and when blocks (the Haskell call-back, that is) the OS thread doesn't grab another Haskell thread to execute, but instead steps aside for an anonymous worker thread to do the job. Makes it all more complicated, alas. Is there no way to get the "current context" explicitly, and treat it as some kind of "handle" that accompanies GLUT calls? I counsel caution here. It's easy to hack something up that will puzzle us for generations. Check out Sigbjorn's notes in the GHC commentary. Whatever we end up doing should be documented there. Simon | -----Original Message----- | From: Wolfgang Thaller [mailto:wolfgang.thaller@gmx.net] | Sent: 16 June 2002 20:57 | To: hopengl(a)haskell.org | Cc: GHC List | Subject: HOpenGL and --enable-threaded-rts | | | In short, it doesn't work :-( . | OpenGL (at least on MacOS) keeps track of the "current context" on a | per-thread basis. The GLUT library sets the current context and calls | back to the program. With GHC 5.03 compiled with | --enable-threaded-rts, | the callback gets executed in a different thread. There is no OpenGL | context set up for that thread, so the first OpenGL call | crashes. This might also be a problem for other state-based | interfaces that use | thread-local state. | | Has anyone already thought about how to solve this problem? | I'm thinking about adding hooks to the RTS (in grabCapability, | releaseCapability and scheduleThread_) which would be used | for setting | up the correct thread-local state whenever Haskell execution | "switches" | to a different OS thread. Those hook routines would have to | be written | in C and would be platform-specific most of the time. It's not a nice | solution, but it's the only one I can think of at this time. | Unless someone comes up with a better idea _quickly_, I'll try it out | and then report how ugly it really is... :-) | | Cheers, | | Wolfgang | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

3 2

hGetContents and threadWaitRead?
by MR K P SCHUPKE 17 Jun '02

17 Jun '02

Whilst everyone is discussing threads, does anybody know if hGetContents is well behaved with respect to threads - ie does it use threadWaitRead internally? I know it uses unsafePerfomIO, is a function that interleaves IO using unsafePerformIO automatically haskell-thread safe? - also do I need to use threadWaitWrite before any hPut - or do the hPut functions do this internally? Regards, Keean Schupke.

2 1

HGL with GHC in Win32
by S.J.Thompson 17 Jun '02

17 Jun '02

Can anyone help? I would like to run a program using the Haskell Graphics Library under GHC on Windows. HGL is listed as a package (when ghc is asked about its packages) but not actually distributed as a package with ghc-5.02.3. On trying to remedy this, - I am able to compile HGL by hand on windows, but on executing the HelloWorld.hs the program hangs: nothing happens. - HGL doesn't appear to compile on unix (solaris). I'd be grateful for any feedback. Thanks very much, Simon Thompson

2 2

HOpenGL and --enable-threaded-rts
by Wolfgang Thaller 16 Jun '02

16 Jun '02

In short, it doesn't work :-( . OpenGL (at least on MacOS) keeps track of the "current context" on a per-thread basis. The GLUT library sets the current context and calls back to the program. With GHC 5.03 compiled with --enable-threaded-rts, the callback gets executed in a different thread. There is no OpenGL context set up for that thread, so the first OpenGL call crashes. This might also be a problem for other state-based interfaces that use thread-local state. Has anyone already thought about how to solve this problem? I'm thinking about adding hooks to the RTS (in grabCapability, releaseCapability and scheduleThread_) which would be used for setting up the correct thread-local state whenever Haskell execution "switches" to a different OS thread. Those hook routines would have to be written in C and would be platform-specific most of the time. It's not a nice solution, but it's the only one I can think of at this time. Unless someone comes up with a better idea _quickly_, I'll try it out and then report how ugly it really is... :-) Cheers, Wolfgang

1 0

sono nuova della rete
by jenny 15 Jun '02

15 Jun '02

http://utenti.lycos.it/jennysexy............................. ..............vienimi a vedere sono nuova della rete

1 0

RE: possible readline license problem with ghc and -package util
by Simon Marlow 15 Jun '02

15 Jun '02

> I have a problem with the readline license that applies to ghc, and > programs compiled with ghc. > > The readline library is under the GPL license. This means that any > program (including ghc) that links with this library must itself be > licensed under the GPL. *Grrrr* Yes, you're right. I hadn't noticed that readline was GPL and not LGPL. The BSD license is "compatible" with the GPL, so according to the FSF, just because GHCi is linked with readline doesn't mean we have to license the whole of GHC and its libraries under the GPL. But we do have to make GHCi "available under the GPL" whatever that means. Actually I'm dubious about the notion of compatible licenses - I read the GPL carefully and I still don't see how it is compatible with the BSD license at all (I'm not the only person to have noticed this, see for example http://www.kallisys.org/bsd-lite/bsd-gpl/?lg=en) I think realistically we have to ditch readline for GHCi and use something with a friendlier license. BSD's libedit is a possibility. As for the readline library that GHC provides, I think that will have to move into its own package: we knew we would have to start a separate package for GPL libraries at some point, it looks like we've reached that stage. This is *so* annoying when all we're trying to do is write free software here. Grrrr. Cheers, Simon

11 19

RE: Updating the net package
by D.J.Steinitz 14 Jun '02

14 Jun '02

Simon, It's built and works on my test sockets program. My next job is to the one line change in SocketPrim.hsc and the one line change to make sure the right header file is included which contains the definition of IP_TTL. Many thanks for all your help, Dominic.

1 0