Re: [Caml-list] Callback in DLL

["Warp" <warplayer@free.fr>]

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