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 NAA19488; Fri, 28 Dec 2001 13:57:14 +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 NAA19424 for ; Fri, 28 Dec 2001 13:57:13 +0100 (MET) Received: from mel-rto3.wanadoo.fr (smtp-out-3.wanadoo.fr [193.252.19.233]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id fBSCvCT07776; Fri, 28 Dec 2001 13:57:12 +0100 (MET) Received: from antholoma.wanadoo.fr (193.252.19.153) by mel-rto3.wanadoo.fr; 28 Dec 2001 13:57:12 +0100 Received: from warp (193.253.253.247) by antholoma.wanadoo.fr; 28 Dec 2001 13:57:12 +0100 Message-ID: <004001c18f9e$e3f58e10$f7fdfdc1@warp> From: "Warp" To: "Xavier Leroy" Cc: "OCaml" References: <12e101c18e3d$1eaa96d0$bdc20b50@warp> <20011228094910.A17635@pauillac.inria.fr> Subject: Re: [Caml-list] Callback in DLL Date: Fri, 28 Dec 2001 13:55:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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. oups ! I didn't see that one ! Ok, lets try.... 1) if I only link ocamlrun.lib, it can't find external "local_roots" needed in CAMLparamX, so I have to use my caml_init_func (dll entry point) and a modified interpreter which call the entry point passing the adress of local_roots. 2) ... and then, my first call to "alloc" is causing a crash inside ocamlrun.lib ( perhaps my modified interpreter is not exporting the function ). More infos : - I got a DLL called camlwlib , which is a modified byterun , adding init calls for dynamic linked libraries and also a Caml_Run exported function which load a bytecode file and run it. - I got a ocamlwrun.exe which only load the camlwlib and call Caml_Run with the first argument - I got my DLL called dllwin32ui - All of theses are build under VC++6 > > 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. Without local_roots, perhaps I only need to link ocamlrun.lib and remove my CAMLparam / local / return Macros ? > > 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. Actually , "v" is returned to the caml, and then let-stored. So it is referenced. > > 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. I'll try this.... > > 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. "unresolved external symbol _local_roots" ---- Thanks a lot, I'll try at least to *bug* in harmony with the GC :) Warp ------------------- 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