Simon Marlow wrote:
This discussion is getting rather long, so I thought I'd summarise (as
much for my benefit as everyone else's). Please let me know if I get
anything wrong.
I haven't found anything wrong.
I'm pretty sure (1) and (2) aren't viable, though.
I basically agree. In the presence
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
Let me ask a naive question concerning the implementation of threading in
the GHC RTS. Would it be feasible to support an alternative strategy for
mapping Haskell threads onto OS threads, namely that the two sets are kept
in one-to-one correspondence? The thread multiplexing and migration that
Simon Marlow wrote:
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?
The libGL supplied with XFree86 uses xthread_{get,set}_specific. These
are macros
| 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
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.
