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
>