Simon Peyton-Jones wrote:
The idea would be that we'd keep the invariant that only one OS thread can be executing Haskell at any moment. So no mutex locks on allocation or thunk entry.
Ah that sounds good. I think I can live with some OS-thread-switching. I think this is the way to go. Is anyone available to implement this? (How long will I have to keep using my own ugly hack?)
Suppose we call one of a Haskell-thread-with-a-dedicated-OS-thread a "Haskell super-thread"
I'd suggest "heavy threads" vs. "light threads" :-). Claus Reinke wrote:
I still like Sven's idea - noone has asked for a new OS thread for the callbacks, so there shouldn't be one, so there shouldn't be a problem with the admittedly not nice use of OS-thread-local storage.
The problem with that is that it will fail miserably (read: crash) if another haskell thread does something that _requires_ an OS thread switch (like call a foreign import threadsafe function). Sven Panne wrote:
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.
I don't think so. Context-switching is a client-side affair. After all, a single-threaded two-window OpenGL application has to switch between its two contexts all the time. Cheers, Wolfgang