> It all works fine for a single pipeline, but I would like to support
> concurrent pipelines where each pipeline is implemented by a separate
> system thread (Linux pthreads).  
> 
> My OCaml pipeline function does a segmentation fault when I do this.
> I have built the OCaml code using the -thread flag, and my link step
> does -lthreadsnat.  I understand that the OCaml runtime is not
> thread-safe, but I got the impression is that using -thread causes it
> to use a single master lock, which is released when calling out to C
> code; making it safe to mix threaded-C with OCaml.

This is almost correct: the master lock is not automatically released
when calling C code, because for short-running C functions this would
be too slow.  Instead, the C function can choose to relinquish and
reacquire the master mutex using enter_blocking_section() and
leave_blocking_section(), e.g.

        value C_function_called_from_Caml(...) {
          /* Convert parameters from Caml to C */
          enter_blocking_section();
          /* Long-running C code that doesn't interact with the Caml runtime */
          leave_blocking_section();
          /* Convert results from C to Caml and return */
        }

I assume your pipeline uses callbacks from C to Caml.  If this is
correct, you also need to reacquire the master mutex before entering Caml
(using leave_blocking_section()) and release it after the Caml
callback has returned (using enter_blocking_section()), e.g.

        leave_blocking_section();
        /* Convert parameters from C to Caml */
        res = callback(closure, argument);
        /* Convert results from Caml to C */
        enter_blocking_section();

> Are the marshalling macros in Chapter 17 (Store_field, etc.) safe wrt
> the OCaml master lock?  

They are safe (just like the whole run-time system) as long as the
master lock is held, i.e. you're not between an enter_blocking_section()
and a leave_blocking_section().

Hope this helps,

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr