From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <goswin-v-b@web.de>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by sympa.inria.fr (Postfix) with ESMTPS id EBC957F722
	for <caml-list@sympa.inria.fr>; Thu, 17 Apr 2014 10:52:33 +0200 (CEST)
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  goswin-v-b@web.de) identity=pra; client-ip=212.227.17.12;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="goswin-v-b@web.de";
  x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  goswin-v-b@web.de) identity=mailfrom;
  client-ip=212.227.17.12;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="goswin-v-b@web.de";
  x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@mout.web.de) identity=helo;
  client-ip=212.227.17.12;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="goswin-v-b@web.de";
  x-sender="postmaster@mout.web.de";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AngBAAiWT1PU4xEMnGdsb2JhbABZwgKHBBYOAQEBAQEGDQkJFCiCZns0BSiIGwEYmCKqZB+HQY4LdIMOgRQEmGmGQhKPLIFo
X-IPAS-Result: AngBAAiWT1PU4xEMnGdsb2JhbABZwgKHBBYOAQEBAQEGDQkJFCiCZns0BSiIGwEYmCKqZB+HQY4LdIMOgRQEmGmGQhKPLIFo
X-IronPort-AV: E=Sophos;i="4.97,877,1389740400"; 
   d="scan'208";a="68686022"
Received: from mout.web.de ([212.227.17.12])
  by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Apr 2014 10:52:28 +0200
Received: from frosties.localnet ([78.43.112.216]) by smtp.web.de (mrweb002)
 with ESMTPSA (Nemesis) id 0MHpKH-1WX8kg2IWL-003bt5 for <caml-list@inria.fr>;
 Thu, 17 Apr 2014 10:52:27 +0200
Received: from mrvn by frosties.localnet with local (Exim 4.80)
	(envelope-from <goswin-v-b@web.de>)
	id 1Wai3W-000510-Pr
	for caml-list@inria.fr; Thu, 17 Apr 2014 10:52:26 +0200
Date: Thu, 17 Apr 2014 10:52:26 +0200
From: Goswin von Brederlow <goswin-v-b@web.de>
To: caml-list@inria.fr
Message-ID: <20140417085226.GA18497@frosties>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Provags-ID:  V03:K0:adkfL+E7gOs3k6/ejWV4AdIDc0MB7wn6JM8NpC5/vgJkSz2ieGw
 O/7A1wyfDbEFIRh7TLusNep1GhW2SgkZZKUfIb6CuKXjf8bokZX3otFvVseeucVip5io0Er
 PqU7UnTMdnCWFXkP3PSZ508Uhk55p2rGLmBSgdutY7mMilucrRVapJScnRjsnGKmiHEumhF
 yxTdIERKSCC4btHPLHdug==
Subject: [Caml-list] How does the Thread module work with the Gc?

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