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 JAA17412; Fri, 28 Dec 2001 09:49:12 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA17107 for ; Fri, 28 Dec 2001 09:49:11 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id fBS8nBT03517; Fri, 28 Dec 2001 09:49:11 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA16471; Fri, 28 Dec 2001 09:49:10 +0100 (MET) Date: Fri, 28 Dec 2001 09:49:10 +0100 From: Xavier Leroy To: Warp Cc: OCaml Subject: Re: [Caml-list] Callback in DLL Message-ID: <20011228094910.A17635@pauillac.inria.fr> References: <12e101c18e3d$1eaa96d0$bdc20b50@warp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <12e101c18e3d$1eaa96d0$bdc20b50@warp>; from warplayer@free.fr on Wed, Dec 26, 2001 at 07:42:49PM +0100 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > I got some problems passing a callback function value to a DLL, which will > call the caml function when some event occurs. > In fact, to use the callback_exn C API function, I have to link with the > libcamlrun library, but that's not why I want to do because an interpreter > ocamlrun ) is already running. If you're building a DLL whose purpose is to be loaded inside ocamlrun, then you should link with ocamlrun.lib, which is an "import library" around the DLL entry points exported by ocamlrun. > Here's a proposal to resolve such a problem : > a DLL should have an EntryPoint ( called CamlEntryPoint for exemple ) and > when it's first load by the run-time system, it call the DLL EntryPoint > function, passing both cprims and names_of_cprims arrays as parameters. Then > we only have to add a "caml" callback func (useless in caml !) to enable DLL > callback. There are many more functions (and global variables) from the runtime system that need to be known to the DLL. The import library solution is a lot easier, especially since the source code of the DLL can also be compiled as a statically-linked library for use with ocamlc -custom. > I don't know how LabTk works... I'll have a look at it. Good idea. You may want to start with a simpler example, e.g. otherlibs/str/Makefile.nt in the OCaml sources. On to your other questions: > I got some trouble with the garbage collector. > I manage to make callbacks from my dynamic linked library, passing it > the callbackN_exn C API function address when it loads. > Now i'm doing theses things : > [Store a Caml value as a window data] > So , the user got the ' v ' caml value which mainly contains the real handle > of the window and the callback. > And the window itself can obtain ' v ' from handle by calling > etWindowData( handle_of_window ); > in the window proc I'm getting that ' v ' data like that and then I'm > calling caml callback. > All it's fine, but after 10 seconds, the garbage collector collects my ' v ' > data ( I can see that the Tag_val is set to Zero ). Of course. You didn't tell it that you've kept a pointer to "v" in the window data. So, as far as the GC is concerned, nobody is pointing to "v", so it can be freed. > How can i prevent that ? > Shall I use CAMLparamX and other garbage-living-in-harmony-stuff ? Yes, you definitely need to learn how to "live in harmony" with the GC :-) Here, CAMLparamX isn't what you need, because "v" isn't local to the C function. You need to use register_global_root(). If you cannot get the memory address where SetWindowData stores its window data, you'll need to put an additional indirection through a malloc()-ed block. > Theses macros are using local_root so do I have to make my library ask the > current local_root from the interpreter ? The import library takes care of all that. - Xavier Leroy ------------------- 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