Question

If I create a thread using forkIO I need to provide a function to run and get back an identifier (threadID). I then can communicate with this animal via e.g. the workloads, MVARs etc.. However, to my understanding the created thread is very limited and can only work in sort of a SIMD fashion where the function that was provided for thread creation is the instruction. I cannot change the function that I provided when the thread was initiated. I understand that these user threads are eventually by the OS mapped to OS threads.

I would like to know how the Haskell threads and the OS threads do interface. Why can Haskell threads that do completely different things be mapped to one and the same OS thread? Why was there no need to initiate the OS thread with a fixed instruction (as it is needed in forkIO)? How does the scheduler(?) recognize user threads in an application that could possibly be distributed? In other words, why are OS threads so flexible?

Last, is there any way to dump the heap of a selected thread from within the application?

Answer 1

First, let’s address one quick misconception:

I understand that these user threads are eventually by the OS mapped to OS threads.

Actually, the Haskell runtime is in charge of choosing which Haskell thread a particular OS thread from its pool is executing.

Now the questions, one at a time.

Why can Haskell threads that do completely different things be mapped to one and the same OS thread?

Ignoring FFI for the moment, all OS threads are actually running the Haskell runtime, which keeps track of a list of ready Haskell threads. The runtime chooses a Haskell thread to execute, and jumps into the code, executing until the thread yields control back to the runtime. At that moment, the runtime has a chance to continue executing the same thread or pick a different one.

In short: many Haskell threads can be mapped to a single OS thread because in reality that OS thread is doing only one thing, namely, running the Haskell runtime.

Why was there no need to initiate the OS thread with a fixed instruction (as it is needed in forkIO)?

I don’t understand this question (and I think it stems from a second misconception). You start OS threads with a fixed instruction in exactly the same sense that you start Haskell threads with a fixed instruction: for each thing, you just give a chunk of code to execute and that’s what it does.

How does the scheduler(?) recognize user threads in an application that could possibly be distributed?

“Distributed” is a dangerous word: usually, it refers to spreading code across multiple machines (presumably not what you meant here). As for how the Haskell runtime can tell when there’s multiple threads, well, that’s easy: you tell it when you call forkIO.

In other words, why are OS threads so flexible?

It’s not clear to me that OS threads are any more flexible than Haskell threads, so this question is a bit strange.

Last, is there any way to dump the heap of a selected thread from within the application?

I actually don’t really know of any tools for dumping the Haskell heap at all, in multithreaded applications or otherwise. You can dump a representation of the part of the heap reachable from a particular object, if you like, using a package like vacuum. I’ve used vacuum-cairo to visualize these dumps with great success in the past.

For further information, you may enjoy the middle two sections, “Conventions” and “Foreign Imports”, from my intro to multithreaded gtk2hs programming, and perhaps also bits of the section on “The Non-Threaded Runtime”.