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