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 (3) or (4) [or (5) ;-) ], my own hack looks like - well - a hack. I'll definitely use it as a short term solution for my own toy projects, though. I won't commit any code, but if anyone else needs a short-term solution for HOpenGL, they can ask me.
Personally I can't decide whether (3) or (4) is the better solution.
I'd say, let's go for (5) - that is, some blend between (3) or (4). (4) almost sounds like (3) could be implemented on top of it. The simplicity of (3) is needed in most cases, the power of something like (4) in some. Some other random thoughts: Does the "OS-thread"-binding have to be a permanent attribute of a thread, or can we also have something like: inOSThread theGLUTThread $ do ... This could be useful for finalizers, or when some thread-sensitive API is used only "some of the time". The problem is that the haskell thread in question could be blocked indefinitely until the OS thread decides to return to Haskell code. I do also like the idea of a forkHeavyIOThread primitive. If something like (4) is implemented, it should still be possible to say that a Haskell thread can run in any OS thread. We never know what new ways of juggling threads (SMP, distributed systems?) will be supported in the future for code that "doesn't mind" being executed in different threads. The current limitations of the RTS (i.e. haskell code can only run in one OS thread at one time) should be a well-documented implementation detail, not a fundamental assumption for the threading primitives. The "don't care" thread group could still support features like the current threaded rts. The documentation will just have to make clear that it can't be predicted which OS thread those haskell threads will be run in, and that some libraries don't like that. CU, Wolfgang