RE: [HOpenGL] HOpenGL and --enable-threaded-rts
| My proposal is to leave dealing with thread-local state to | the library | binding (in this case, HOpenGL). This requires just a little support | from the RTS. The library binding would have to include C-language | routines that get called by the RTS at certain points: | * when the RTS starts executing Haskell code in an OS thread | (grabCapability) | * when the RTS stops executing Haskell code in an OS thread | (releaseCapability) | * when the RTS is about to spawn a new thread in response to | a callback (scheduleThread_). That might be ok provided there was a single context "in play". In effect, your proposal amounts to keeping a process-global context, and zapping it into the Current Haskell Worker Thread whenever it grabs a capability, correct? But if there's a single global context, why does it need to be thread-local? Another possibility that Simon and I have discussed is to provide a sort of forkIO that says "create a Haskell thread permanently bound to an OS thread". Much more expensive than normal forkIO. More like having a permanent secretary at your beck and call, rather than the services of a typist from the typing pool. Simon
Simon Peyton-Jones wrote:
That might be ok provided there was a single context "in play". In effect, your proposal amounts to keeping a process-global context, and zapping it into the Current Haskell Worker Thread whenever it grabs a capability, correct?
Correct. A little more work (Haskell-Thread-Local storage and one or two more RTS callbacks) would be required to use OpenGL from multiple haskell threads at the same time. However my actual proposal has nothing to do with OpenGL. Rather, I'd say "extend the RTS to allow library bindings to do this or similar things". I'm not proposing to put anything OpenGL-specific into the RTS.
But if there's a single global context, why does it need to be thread-local?
? I don't follow you. OpenGL can deal with multiple contexts, and it keeps the current context in thread-local state, so it can even deal with multiple contexts at the same time. We can't prevent OpenGL from using thread-local state. The "first version" of the proposed solution would only allow a single global context at one time for HOpenGL, and copy that to the thread-local state of every thread that executes haskell code. If we need to use OpenGL (or similar APIs) from several Haskell threads simultaneously, we will need a place to store a haskell-thread-local context (ideally, this would be a generall mechanism for haskell-thread-local store) and an additional callback from schedule().
Another possibility that Simon and I have discussed is to provide a sort of forkIO that says "create a Haskell thread permanently bound to an OS thread". Much more expensive than normal forkIO. More like having a permanent secretary at your beck and call, rather than the services of a typist from the typing pool.
So calling C from this thread would happen inside that OS thread, callbacks would happen in that OS thread, and the RTS would continue to run while that OS thread is blocked? How much overhead would that create? I wouldn't like much additional overhead for my OpenGL programs :-(. Would this require an OS mutex lock for every heap allocation, or is there a better way? Cheers, Wolfgang
G'day all. On Thu, Jun 20, 2002 at 12:54:25AM +0200, Wolfgang Thaller wrote:
? I don't follow you. OpenGL can deal with multiple contexts, and it keeps the current context in thread-local state, so it can even deal with multiple contexts at the same time. We can't prevent OpenGL from using thread-local state. The "first version" of the proposed solution would only allow a single global context at one time for HOpenGL, and copy that to the thread-local state of every thread that executes haskell code.
I just had another idea. Would it be sufficient to exclusively bind a thread to a specific (albeit arbitrary) OS thread on a temporary basis, kind of like a lock or a transaction? I've never seen an non-GLUT OpenGL program which needs the thread local storage for long. Usually just for the duration of a single update is sufficient. That way you keep the efficiency of Haskell's thread scheduling where you can and bypass it where you can't. Disclaimer: My experience is in visual effects. Our software ran at "interactive" speeds, not "real time". The rules of other industries, such as games, might be different. Cheers, Andrew Bromage
participants (3)
-
Andrew J Bromage -
Simon Peyton-Jones -
Wolfgang Thaller