caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] Implementing co-op threads in ocaml
@ 2005-08-12 14:56 Jonathan Roewen
  2005-08-12 20:47 ` Jonathan Roewen
  0 siblings, 1 reply; 2+ messages in thread
From: Jonathan Roewen @ 2005-08-12 14:56 UTC (permalink / raw)
  To: caml-list

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Caml-list] Implementing co-op threads in ocaml
  2005-08-12 14:56 [Caml-list] Implementing co-op threads in ocaml Jonathan Roewen
@ 2005-08-12 20:47 ` Jonathan Roewen
  0 siblings, 0 replies; 2+ messages in thread
From: Jonathan Roewen @ 2005-08-12 20:47 UTC (permalink / raw)
  To: caml-list

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
>


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-08-12 20:47 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-08-12 14:56 [Caml-list] Implementing co-op threads in ocaml Jonathan Roewen
2005-08-12 20:47 ` Jonathan Roewen

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).