[fpc-pascal] DLL calling Firebird: slow and crashes at the end
Mark Morgan Lloyd
markMLl.fpc-pascal at telemetry.co.uk
Sat Sep 27 14:49:14 CEST 2014
Reinier Olislagers wrote:
> On 26/09/2014 21:41, Mark Morgan Lloyd wrote:
>> Reinier Olislagers wrote:
>>>> If using pchars: is the program doing all storage allocation for these
>>>> or is the DLL also allocating memory?
>>> The DLL is generating those pchars.
>> What frees them?
> Heh ;)
> Ok, I think I've got it worked out now: calling application is
> responsible for memory.
> Does that look about ok?
I think so, but the important thing is that the DLL ("shared object" on
unix) and main program might end up with their own memory managers, and
it's important that memory be released in the same (logical) place as
it's allocated. In Lazarus/LCL there's comparable considerations in
resource handling, e.g. menus etc.
>>>> I thought Holland /was/ flat :-) I was again thinking of the case where
>>>> both the main program and the DLL were your code. Using shortstrings
>>>> removes some of the dynamic allocation, hence potentially the need for a
>>>> single memory manager (cmem).
> Ok, but I want it to be usable in Delphi, Excel etc...
Reasonable. From the POV of a Delphi/FPC caller, somewhere I've got a
class which can encapsulate a DLL/so so that it can be opened on demand,
the entry points become methods i.e. instance.function(). In one case
I've contrived to also support static linkage for easier debugging, in
which case the entry point looks like a conventional unit.function().
>> Always a pleasure. Spent the evening herding sheep: 80m above sea level,
>> which around here are called Downs :-)
> Crazy Welshmen ... ;) Maybe that's what you get when the altitude
> starts affecting your blood oxygen levels.
Guilty, but residing in England. > Some Celtic derivation according
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
More information about the fpc-pascal