RE: [HOpenGL] HOpenGL and --enable-threaded-rts
Simon and I have discussed this multi-threading question a bit. This message tries to summarise the story as we understand it. GHC's approach to threading ~~~~~~~~~~~~~~~~~~~~ Make certain you read the "Supporting multi-threaded inter-operation" section of the GHC commentary http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/rts-libs/multi-thread. html The current GHC model has the basic assumption that OS threads are inter-changeable. One Haskell thread may be executed by one OS thread or by many; you just can't tell. There is a good reason for this: the current OS thread may block in some I/O call (getChar, say), and we don't want that to block all Haskell threads. If you want all Haskell threads executed by a single OS thread, then you don't want --enable-threaded-rts, and your I/O calls may block all Haskell threads. There is no notion of a Haskell-thread-local location right now. We don't know how to make it type-safe. If you want that, you have to define your own environment monad, which isn't too hard. Or use implicit parameters, also not hard. GLUT's approach to threading ~~~~~~~~~~~~~~~~~~~~~ Simon and I don't understand GLUT's requirements at all clearly. Why is the context thread-local? Because different threads can have different contexts? Do you really need that? If not, would it suffice to make all the threads have (a pointer to) the same context)? Much the tidiest thing is to make the context an explicit parameter to GLUT calls. Or, if there is only one context of interest, keep it in a process-global location (not thread-local) and, sigh, heave it into the thread-local location before every GLUT call. In short, we don't understand GLUT well enough to be able to propose a solution. I hope that the above remarks may help the GLUT experts understand GHC well enough to write down a summary of what is going on. Try not to rely on someone having read all the past mail! Simon | -----Original Message----- | From: Sven Panne [mailto:Sven_Panne@BetaResearch.de] | Sent: 18 June 2002 15:06 | To: hopengl@haskell.org | Cc: GHC List | Subject: Re: [HOpenGL] HOpenGL and --enable-threaded-rts | | | Simon Marlow wrote: | > [...] a given Haskell thread can even migrate from one OS thread to | > another during its execution. | | Uh, oh! %-( Under which circumstances exactly? I fear this | will give loads of fun with many C libraries out there, so | it's important to know... | | Cheers, | S. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |
Simon Peyton-Jones wrote:
[...] GHC's approach to threading [...] The current GHC model has the basic assumption that OS threads are inter-changeable.
As has already been mentioned by others, this assumption doesn't hold if you leave the Happy World of Haskell(tm): Locks/mutexes/... and thread-local variables can be hidden under the hoods of many libraries out there, for which there will *never* be a Haskell replacement. I consider the ability to write bindings to those libraries as an extremely important point, otherwise the usefulness of Haskell is rather limited. Remember that Haskell has been described as a "good glue" for other building blocks (= APIs) around...
[...] There is a good reason for this: the current OS thread may block in some I/O call (getChar, say), and we don't want that to block all Haskell threads.
Hmmm, I don't consider this a good reason. IMHO there are basically 2 ways for threading in an RTS: * The "Green Threads" approach, where no OS threading is used, but everything is done by hand, 'select'-ing carefully internally, etc. If the user itself calls out to C land and gets blocked, the whole RTS is blocked. Not nice, but the price to pay for getting flyweight threads. * A 1-1 mapping from the threads in the language in question to OS threads. If there is a danger of blocking, the user forks away a new thread to do the work, and everything is fine. The Java world lives quite happily with this. Anything between will be doomed to fail in the general case, I fear, for the reasons given in this (mail- :-) thread. It is OK if no external code is ever called, but then you may use "Green Threads", anyway... Hacking GLUT to work with GHC's current approach makes no sense, it would only solve a single instance of a general problem. Furthermore, it would be extremely system-dependent and would cost a *vast* amount of performance: Switching OpenGL contexts can require a round-trip to a remote server, can trigger swapping a few MB of textures into your favourite graphics card, etc. OK, these are worst-case scenarios, but doing even the best case just for drawing a few vertices would probably be ridiculously slow. Cheers, S.
participants (2)
-
Simon Peyton-Jones -
Sven Panne