From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 38813BCA2 for ; Fri, 12 Aug 2005 22:47:07 +0200 (CEST) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j7CKl64e007348 for ; Fri, 12 Aug 2005 22:47:06 +0200 Received: by rproxy.gmail.com with SMTP id a36so611091rnf for ; Fri, 12 Aug 2005 13:47:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Sa5zeevu21+p1zwC5mqDZPaM2Fp0V+UcSbHbwmIvB2t+gwPffblKOQV2WSI84nBtB0T/mWb5M9joZTxxaEqux3tn+igouQlOjtKJpRdswTMB0YoG4bPdsRSqpjlGXNNOJVOU+nUig03BujRUpaM/59yMd3z4GOpd3s4nuH4gIs0= Received: by 10.38.181.31 with SMTP id d31mr918124rnf; Fri, 12 Aug 2005 13:47:06 -0700 (PDT) Received: by 10.38.209.44 with HTTP; Fri, 12 Aug 2005 13:47:06 -0700 (PDT) Message-ID: Date: Sat, 13 Aug 2005 08:47:06 +1200 From: Jonathan Roewen To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Implementing co-op threads in ocaml In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Miltered: at nez-perce with ID 42FD0ACA.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 threads:01 ocaml:01 compilers:01 ocaml:01 threading:01 systhreads:01 char:01 stack:01 stack:01 char:01 pointer:01 pointer:01 struct:01 heap:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_BY_IP autolearn=disabled version=3.0.3 Another thought: is there any way to modify the compilers to generate a function call after every so many ocaml instructions? For example, a Thread.yield () in order to provide some sort of quasi-realtime constraints (and prevent apps from not yielding in a non-allocating loop). Jonathan On 8/13/05, Jonathan Roewen wrote: > Hi, >=20 > I have a few questions about how to allocate some C-side values in an > ocaml type, for the purposes of implementing custom threading in a > native app. >=20 > After reading through some systhreads code, I've come up with the > notion that the following 5 C-land values are probably key to making > this work: >=20 > char * bottom_of_stack; /* Saved value of caml_bottom_of_stack */ > unsigned long last_retaddr; /* Saved value of caml_last_return_address= */ > value * gc_regs; /* Saved value of caml_gc_regs */ > char * exception_pointer; /* Saved value of caml_exception_pointer *= / > struct caml__roots_block * local_roots; /* Saved value of local_roots */ >=20 > I've been trying to make sense of all the rules and things in the > ocaml manuals for storing C data in an ocaml value, but am having some > trouble. Especially with gc_regs, which I assume points to a value > inside the ocaml heap. >=20 > For the purposes of the rules that everything being on a 32-bit > boundary, all the pointers would be fine, and the fact that > last_retaddr is a 32bit value, all this would be fine. >=20 > Since I'm doing co-op threading primarily in OCaml, I'm also assuming > I don't need to create custom stacks for each thread (such as in C), > and having to swap stacks; therefore, access to ocaml global > values/functions should be fine. Is this assumption correct? >=20 > Am I also correct to think that the only real trick to this would be > making sure the GC scans all thread roots? If say my threads are in a > list, I could have an external function that scans the thread, and > just iter over this list? >=20 > I'm especially interested in how to correctly handle the C-specifics > for storing the pointers and things, but other feedback is also > welcome =3D) >=20 > Jonathan >