From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA21251; Tue, 4 Dec 2001 15:00:29 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA21257 for caml-list@pauillac.inria.fr; Tue, 4 Dec 2001 15:00:28 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA18274 for ; Tue, 4 Dec 2001 11:53:15 +0100 (MET) Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id fB4ArDj17488 for ; Tue, 4 Dec 2001 11:53:14 +0100 (MET) Received: (qmail 466 invoked by uid 50); 4 Dec 2001 10:53:12 -0000 Delivered-To: fixup-caml-list@inria.fr@fixme Received: (qmail 454 invoked by uid 0); 4 Dec 2001 10:53:11 -0000 Received: from 216-161-146-31.customers.uswest.net (HELO dylan) (216.161.146.31) by tcsnpop1.tcsn.uswest.net with SMTP; 4 Dec 2001 10:53:11 -0000 Message-ID: <002001c17cb2$00515e40$210148bf@dylan> From: "David McClain" To: Subject: [Caml-list] DLL's and Systhreads Date: Tue, 4 Dec 2001 03:54:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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