[Caml-list] How does the Thread module work with the Gc?

[Goswin von Brederlow <goswin-v-b@web.de>]

Hi,

as mentioned before I'm porting ocaml to run baremetal on a Raspberry
Pi and I'm getting close to a first release. Maybe porting is the
wrong word. I'm writing an exo kernel that you link to the ocamlopt
output to create a bootable kernel image. So just a verry thin layer
between hardware and ocaml.

What I'm currently a bit stuck with is the threading support and
interrupts. Since I don't plan to implement the pthread interface I
have to write my own Thread module. But it is verry similar to
otherlibs/systhread/ by necessity.

There seems to be 3 parts where the Thread module interacts with the Gc:

1) scan_roots_hook

This handles the per thread local roots, stacks and gc registers. This
ensures that data seen by any thread remains alive. Otherwise only
data seen by the current thread would be seen by the Gc.

2) stack usage estimation

No idea what that is for. It seems to add up the stack usage per
thread.

3) enter/leave_blocking_section

There is a mutex that prevents any two threads from leaving the
blocking section. I.e. no two threads can ever run ocaml code.

This is where the thread switching happens in the Thread module. This
causes threads to switch when you call e.g. Printf.printf.


But here is where my problem starts:

How does ocaml switch threads when a signal occurs? What if a thread
never enters a blocking section? Isn't there some other point where
tasks can be switched other than enter/leave_blocking_section?

I looked at the implementation for signals and they seem to set the
allocation limit for the thread to 0 so the next allocation will
trigger a Gc run. But how does that lead to a thread switch? What am I
missing here?

MfG
	Goswin