[Caml-list] calling ocaml from threaded C program

[Trevor Jim]

I'm having some crashes with a threaded C program that calls
ocaml code. (Unison on Mac OS X.)

This discussion:

http://groups.google.com/group/fa.caml/browse_thread/thread/684a6f1647fdbe3/e4ad7e1e8fca5edb?lnk=gst&q=threads&rnum=1#e4ad7e1e8fca5edb

provides some good information, but I could use some more info.
(And I hope this will make it into the manual at some point.)

Specifically:

The program is an ObjC program, a GUI wrapped around an ocaml program
(Unison). The ObjC program is multithreaded. From the above discussion
I realize that only one of the ObjC threads can call back to ocaml at
any given time, therefore I have a lock for ocaml callbacks (a posix
threads mutex).

However, I still get crashes. I think I must be missing some locking.
So far I have locked ObjC calls to caml_callback, caml_callback_exn,
etc. I have not locked certain other calls of the caml C API, e.g.,

caml_named_value()
caml_copy_string()
caml_remove_global_root()
caml_register_global_root()
Val_int()
Field()
String_val()
Wosize_val()

If anyone knows exactly what parts of the ocaml C API need to be locked
for this scenario, it would be nice to have that in the documentation.

Also, I wonder whether there is any issue with having one ObjC thread
in the ocaml runtime, while another ObjC thread accesses an object
that is either an ocaml root or accessible from an ocaml root -- is
any locking required?

Thanks for any info,
Trevor

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

[Markus Mottl]

On 1/8/07, Trevor Jim <tre...@research.att.com> wrote:
>
> However, I still get crashes. I think I must be missing some locking.
> So far I have locked ObjC calls to caml_callback, caml_callback_exn,
> etc. I have not locked certain other calls of the caml C API, e.g.,
>
> caml_named_value()
> caml_copy_string()
> caml_remove_global_root()
> caml_register_global_root()
> Val_int()
> Field()
> String_val()
> Wosize_val()

With the exception of "Val_int" none of the above is thread-safe. Since the
GC can move values at anytime while your C-thread is executing, any
C-function that accepts or returns a "value" (= OCaml-value) is potentially
unsafe. Val_int is an exception, because OCaml-ints are unboxed (btw.
unlike int32, int64, nativeint!). Atomic (also atomic polymorphic) variants
and characters, too, are unboxed and can therefore be safely handled by
C-threads at any time.

Furthermore, it is safe to access the contents of bigarrays if they cannot
be reclaimed during that time (e.g. because you protected them before
releasing the OCaml-lock using CAMLparam, etc.), because their contents is
outside of the OCaml-heap.

Otherwise never access OCaml-values from a C-thread if there are running
OCaml-threads. Here be dragons...

If anyone knows exactly what parts of the ocaml C API need to be locked
> for this scenario, it would be nice to have that in the documentation.

Yes, that would be nice indeed...

Also, I wonder whether there is any issue with having one ObjC thread
> in the ocaml runtime, while another ObjC thread accesses an object
> that is either an ocaml root or accessible from an ocaml root -- is
> any locking required?

The OCaml-GC may run at anytime and mess with the existence and position of
OCaml-values. Thus, you cannot do what you want here without locking.

Regards,
Markus

--
Markus Mottl http://www.ocaml.info markus...@gmail.com

[Trevor Jim]

Thanks. Maybe someone on the list has some experience and
could contribute some advice...

What I have is a long-running ocaml thread, invoked from Objc,
and I would like to have other Objc threads running that
report on the progress of the ocaml thread, etc. That means
communication between the ocaml thread and the Objc threads,
which I now know cannot occur using most functions of the
ocaml C api.

So any advice on the best way to communicate between these
threads?

I am guessing I need to having locking implemented in Objc
and exported to ocaml, then both the ocaml thread and the
Objc threads can synchronize. Then I can for example
allocate a buffer in Objc and export it to ocaml and the
threads can communicate over the buffer using the locking
as necessary. Or this might be packaged up a bit more
nicely, but the locking and storage must be done on the
Objc side.

-Trevor