On 7/25/05, Simon Marlow
On 23 July 2005 03:38, Duncan Coutts wrote:
The problem then as John noted is that the main loop of these toolkits block and so the other Haskell threads would not get a chance to schedule. So the challenge is to give the Haskell threads a chance to schedule.
[ good description of the multi-threaded GUI problem deleted ]
Thanks for describing the problem in detail, I understand it better now. I think it comes down to this conflict:
- you want to take advantage of the fact that GHC has lightweight "green" threads in order to do multithreading within a single OS thread, but
- our "bound threads" design does not require the implementation to support lightweight threads, and hence doesn't let the programmer take advantage of them.
Well how about not touching the "bound threads" design at all, but modifying the lightweigh threads design to also include "forkIOHere" (or something) which would produce a lightweight thread which is always run in the "main" OS thread. That way you could just start doing GUI calls in the main thread and then anywhere you please spawn off lightweight threads which can also do GUI calls since they all get scheduled to run in the same OS thread as "main". So instead of changing the "bound threads" design you simiply make the GHC "optimization" of using lightweigh threads offer more control to the programmer. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862