From: "Daniel Bünzli" <daniel.buenzli@epfl.ch>
To: annan@hushmail.com
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] C interface, threads and ocaml callbacks
Date: Wed, 10 Mar 2004 01:24:27 +0100 [thread overview]
Message-ID: <4A6D8484-7229-11D8-8391-000393DBC266@epfl.ch> (raw)
In-Reply-To: <200403050213.i252DtGV029925@mailserver2.hushmail.com>
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
next parent reply other threads:[~2004-03-10 0:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200403050213.i252DtGV029925@mailserver2.hushmail.com>
2004-03-10 0:24 ` Daniel Bünzli [this message]
2004-03-03 22:51 Daniel Bünzli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A6D8484-7229-11D8-8391-000393DBC266@epfl.ch \
--to=daniel.buenzli@epfl.ch \
--cc=annan@hushmail.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox