On 08/15/2011 09:14 PM, Marcos Douglas wrote:
What about memory leaks. Have you tested?
+1
Thanks for providing your results, Juan.
Some more background:
(AFAIK:)
A normal Lazarus/FPC (and Delphi) created SO (shared object) ( =
Windows DLL, Linux .so, Mac ???, ...???) instantiates its own
independent memory manager. This is perfectly fine, as it does not know
in what language the calling program is done and what memory manager
same uses.
The Plus is that it just works, the Minus is that the interface between
the program and the SO always needs to be "flat" (just using simple C
compatible types, no Objects no Pascal Strings etc.)
The SO is not supposed to do anything on it's own but is just a
"library" of functions that can be called
Thus such a SO is not supposed to provide any kind of GUI, neither
reusing the GUI of the main program nor creating its own GUI binding.
As a result e.g. TTimer will not work (or at least is not supposed to
work).
A SO can use threads to implement "free running" activities. AFAIK, you
can use TThread instances for this, but any normal (portable,
LCL-defined) communication with the main Thread (such as
TThread.Synchronize and Application.QueueAsyncCall) is not allowed.
Now it does make sense to use Pascal SOs from Pascal programs (e.g. for
creating a "plug in" system).
Here it is highly desirable to use a non-flat interface, communicating
objects and Pascal stings. This in fact is possible (I did test it with
Delphi but AFAIK something similar is provided for Lazarus/FPC as well)
by using a memory manager in the SO that hooks into the main program's
memory manager.
Now in the end a SO-designer might want to provide a GUI for his SO.
Here in theory two alternatives are possible (1) plugging into the GUI
of the main program and (2) do a completely independent GUI.
For (1) is seems obvious that the main program needs to be done in
Lazarus/FPC as well and a common memory manager needs to be used. (thus
aiming to a very tight integration).
For (2) the main program does not need to be done in Lazarus/FPC and it
is not necessary (but possible) to use a common memory manager (thus
aiming to a rather self-contained SO). IMHO, to make this decently
work, the SO needs it's own independent "main thread" and do a GUI
binding (aka TApplication instance) for same. With that normal GUI work
and things like TTimer, TThread.Synchronize and
Application.QueueAsyncCall can work (completely internally in the DLL).
How to do a notification of events generated in the DLL onto the main
program (and vice versa) is an additional question. It should be
achieved e.g.by Application.QueueAsyncCall using the other site's
TApplication instance in case the main project in fact is done by
Lazarus and by some kind of "callback" in case of the main program done
somehow else.
Conclusion:
It would be great, if Lazarus would provide a kind of "SO-Application"
project prototype that allows for all this in a decently reliable and
verified and portable way.
The user should be allowed to select if (s)he want to use
(a) a common memory manager or not ("Yes" forces that the main program
is done in Lazarus, too) and
(b) no, a shared, or an independent GUI ("shared" forces a common memory
manager)
for the SO.
Of course some support for the main program for providing the
appropriate hooks for the SO needs to be necessary.
have fun :-) ,
-Michael
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
