caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "David McClain" <barabh@qwest.net>
To: <caml-list@inria.fr>
Subject: [Caml-list] DLL's and Systhreads
Date: Tue, 4 Dec 2001 03:54:08 -0700	[thread overview]
Message-ID: <002001c17cb2$00515e40$210148bf@dylan> (raw)

Jeff Henrikson wrote:

I also need to expose caml code in a DLL.  Could you post your working
thread code/event loop so that I can avoid hacking around?

-----------------

I now have a complete "kit" for making foreign language DLL's (Lisp &
OCaml). This kit takes a very simple interface specification and
automatically generates the glue code between C/C++, Lisp, and OCaml. A
C/C++ header is generated that is shared between client code and the C/C++
wrappers around the DLL's. Also, for both Lisp and OCaml, I generate some
standard DLL bridge code to handle the thread communications in a standard
way. This includes unmarshalling function arguments for OCaml. The user can
go ahead and write the DLL routines in the HLL without any concern for
communication protocols.

Both the Ocaml and Lisp wrapper routines use a dedicated thread for
initializing the backend foreign DLL, and then acting as a messenger for
client threads to the backend DLL. That backend DLL is free to implement its
own multithreading, if it chooses. Otherwise this creates a many-to-one
threading control.

I will endeavor to post this code somewhere, but until I do, just ask me for
a copy of the zip files for this foreign DLL bridging, if you need it
sooner.

----------------------------------
Jeff wrote:

Do you have any idea what will happen with windows dynamic linking behavior
if two such DLLs get loaded into the same process
space?  It'd be cool if they could share runtimes, but I doubt that would be
an easy or free behavior.  I'm not even sure you would
get correct separation of two runtimes for free.  I'd have to test the
linker scoping behavior.

-----------------------------------
I have been wondering about this myself. Since the DLL's are loaded
independently of each other, there should be no direct sharing of
information, unless the code has established surreptitious channels in the
form of system-wide global data. With my technique of bridging to foreign
backends on a dedicated main thread, even the threading system should keep
them apart. That is to say, that even though, e.g., the OCaml threading code
uses Thread Local Store, each DLL will have been started on a separate
thread.

It will be an interesting experiment, but I cannot yet answer how well it
works. I certainly coded with this possibility in mind, and, hopefully, I
haven't done anything that would preclude it.

Cheers,

- DM
-------------------
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


                 reply	other threads:[~2001-12-04 14:00 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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='002001c17cb2$00515e40$210148bf@dylan' \
    --to=barabh@qwest.net \
    --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;
as well as URLs for NNTP newsgroup(s).