* [Caml-list] C interface, threads and ocaml callbacks
@ 2004-03-03 22:51 Daniel Bünzli
0 siblings, 0 replies; 2+ messages in thread
From: Daniel Bünzli @ 2004-03-03 22:51 UTC (permalink / raw)
To: caml-list
Hello,
I'm trying to do a binding from ocaml to a C function f which may spawn
threads when invoked. These threads may concurrently try to invoke
ocaml registrated callbacks. However when f returns I'm guaranteed that
all spawn threads have terminated.
I'm aware of these messages [1] but I'm not sure I really got the
point. My understanding is that two threads should not callback into
caml at the same time and that in order to do so, the following should
be done. If anyone could comment/correct.
1. Link and compile everything used by the program invoking the stub to
f
with the option -thread.
2. In the stub to function f, bracket the call to f with
enter/leave_blocking_section().
CAMLprim value f_stub (value v)
{ /* convert arguments */
enter_blocking_section()
res = f(arg) /* In this function threads will try to concurently
access ocaml */
leave_blocking_section()
/* convert result of f() */
}
3. Around any call from f back into caml, bracket code with
leave/enter_blocking_section.
leave_blocking_section()
/* convert parameters */
res = callback(closure,arg)
/* convert result */
enter_blocking_section()
4. The user of the stub should not use caml threads in the ocaml code
(at all or only in the callbacks ?) and not link against caml threading
libraries (even if I tell f() to stay single threaded but using the
same stub code ?).
Thanks for your answers,
Daniel
P.S. Is that somewhere documented ?
[1]
<http://caml.inria.fr/archives/200308/msg00258.html>
<http://caml.inria.fr/archives/200106/msg00199.html>
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
^ permalink raw reply [flat|nested] 2+ messages in thread
[parent not found: <200403050213.i252DtGV029925@mailserver2.hushmail.com>]
* Re: [Caml-list] C interface, threads and ocaml callbacks
[not found] <200403050213.i252DtGV029925@mailserver2.hushmail.com>
@ 2004-03-10 0:24 ` Daniel Bünzli
0 siblings, 0 replies; 2+ messages in thread
From: Daniel Bünzli @ 2004-03-10 0:24 UTC (permalink / raw)
To: annan; +Cc: caml-list
Le 5 mars 04, à 03:13, annan@hushmail.com a écrit :
> If I understand what you are trying to do, most likely you can't do
> it. If you build ocaml code with -threads, you like with the thread-
> aware basic library. Once you do this, you can't use threads you
> created
> in the C execution context, as there is information required by Ocaml
> when executing library functions that gets created when *IT* uses
> threads,
> that isn't there when C creates threads.
>
> So if you create all of your threads in Ocaml, then you can use
> -threads,
> but if C creates threads, those threads cannot execute OCaml code.
My understanding of the -thread flag --- drawn from message [1] --- is
that when you compile with it, then you just get this master lock on
the runtime that you can release/get by using
enter/leave_blocking_section functions. Though the initial purpose of
the latter functions was --- it seems --- to give the opportunity to
ocaml signal handlers to execute during long running C code that
doesn't interact with ocaml, it seems that you can also use this
mechanism to serialize concurrent callbacks from C into ocaml (by
wrapping the callbacks around leave/enter_blocking_section to
get/release the master lock).
> You can have C threads execute inside Ocaml, if you don't use the
> OCaml
> threading library.
This seems match what is described in that message [2], though --- due
to my lack of knowledge about the internals of ocaml's threading
libraries --- I don't really understand the reason.
> So if you can get away with just one OCaml thread,
> but need multiple C threads, then gatekeep the entry of C threads into
> the OCaml code (ie have the OCaml code go through a C function that
> pthread_cond_waits
A lock/unlock on a mutex around the callbacks from C into caml should
be sufficent, hence the use of -thread and
enter/leave_blocking_section.
Unfortunately I hadn't any time these days to experiment the approach I
described in my previous message.
Thanks for you answer.
Daniel
[1] <http://caml.inria.fr/archives/200106/msg00199.html>
[2] <http://caml.inria.fr/archives/200308/msg00258.html>
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2004-03-10 0:23 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-03 22:51 [Caml-list] C interface, threads and ocaml callbacks Daniel Bünzli
[not found] <200403050213.i252DtGV029925@mailserver2.hushmail.com>
2004-03-10 0:24 ` Daniel Bünzli
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox