caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jonathan Roewen <jonathan.roewen@gmail.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Implementing co-op threads in ocaml
Date: Sat, 13 Aug 2005 08:47:06 +1200	[thread overview]
Message-ID: <ad8cfe7e05081213471e620b43@mail.gmail.com> (raw)
In-Reply-To: <ad8cfe7e0508120756149e91c4@mail.gmail.com>

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 <jonathan.roewen@gmail.com> wrote:
> Hi,
> 
> 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.
> 
> 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:
> 
>  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 */
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 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?
> 
> I'm especially interested in how to correctly handle the C-specifics
> for storing the pointers and things, but other feedback is also
> welcome =)
> 
> Jonathan
>


      reply	other threads:[~2005-08-12 20:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-12 14:56 Jonathan Roewen
2005-08-12 20:47 ` Jonathan Roewen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ad8cfe7e05081213471e620b43@mail.gmail.com \
    --to=jonathan.roewen@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).