Re: [fpc-pascal] DLL calling Firebird: slow and crashes at the end
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 [1]... ;) Maybe that's what you get when the altitude
starts affecting your blood oxygen levels.
Guilty, but residing in England. >[1] Some Celtic derivation according
to Wp.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DLL calling Firebird: slow and crashes at the end
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.
Thanks to a Rudy Velthuis article on PChars, I got this for the library
code:
// Returns bytes written to TargetPChar
function DLLPassString(SourceString: string; TargetPChar: PChar;
MaxLength: integer): integer;
begin
if (TargetPChar<>nil) and (MaxLength>1) then
begin
StrLCopy(TargetPChar,PChar(SourceString),MaxLength-1);
result:=StrLen(TargetPChar); //number of bytes in result
{$IFDEF DPDLLDEBUG}
writeln('DLL: DLLPassString got TargetPChar ',TargetPChar);
writeln('DLL: DLLPassString got Result ',Result);
{$ENDIF}
end
else
begin
{$IFDEF DPDLLDEBUG}
writeln('DLL: DLLPassString got nil TargetPChar or maxlength=0 for
sourcestring '+SourceString);
{$ENDIF}
result:=0;
end;
end;
// Returns bytes written and city in City.
// CIty must be assigned by caller;
// maxlen must contain maximum size of City
function GetCity(City:PChar; MaxLen:integer): integer; {$IFDEF
MSWINDOWS}stdcall{$ELSE}cdecl{$ENDIF};
begin
result:=DLLPassString(Address.City,City,MaxLen);
end;
and conversely:
// Passes city ready for ValidateAddress. Pass empty value if unknown.
procedure SetCity(City: PChar); {$IFDEF
MSWINDOWS}stdcall{$ELSE}cdecl{$ENDIF};
begin
Address.City:=City;
end;
Does that look about ok?
>>> 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...
> Always a pleasure. Spent the evening herding sheep: 80m above sea level,
> which around here are called Downs :-)
Crazy Welshmen [1]... ;) Maybe that's what you get when the altitude
starts affecting your blood oxygen levels.
At least over here down below the sea we've got plenty of oxygen - what
we do with it is another story ;)
[1] Just guessing... name+sheep+down=up?!!? :)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DLL calling Firebird: slow and crashes at the end
Reinier Olislagers wrote: Let me explain: postcode.lpr: Lazarus GUI program with LCL etc that uses business layer (+db layer etc) dlldemo.lpr: console application that demonstrates use of dutchpostcode.lpr: dll source using business layer (which calls db units etc - business layer is the same unit as used in GUI program) 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? 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. As said, haven't included cmem... will come back on this tomorrow. Thanks for the help so far! Always a pleasure. Spent the evening herding sheep: 80m above sea level, which around here are called Downs :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DLL calling Firebird: slow and crashes at the end
On 26/09/2014 17:41, Mark Morgan Lloyd wrote: > Reinier Olislagers wrote: > I'm in the middle of kernel test builds at the moment, so forgive me if > I'm not giving your posted example as much attention as it deserves. I understand, thanks. Have quit coding for the day myself, will get back on this tomorrow... > I > was assuming that you'd written both the main program and the DLL, which > would have been analogous to the program I checked (which also used the > LCL etc.). Let me explain: postcode.lpr: Lazarus GUI program with LCL etc that uses business layer (+db layer etc) dlldemo.lpr: console application that demonstrates use of dutchpostcode.lpr: dll source using business layer (which calls db units etc - business layer is the same unit as used in GUI program) > 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. > 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. As said, haven't included cmem... will come back on this tomorrow. Thanks for the help so far! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DLL calling Firebird: slow and crashes at the end
Reinier Olislagers wrote: On 26/09/2014 17:06, Mark Morgan Lloyd wrote: For Linux, cmem before HeapTrc before cthreads before Classes etc., in both main program and DLL. Otherwise play with String[255] etc. Thanks. Currently not using cmem or heaptrc or cthreads. (The "regular" GUI application using the db etc units doesn't either) Currently trying to get my Linux VM going again (or reinstalling)... will test it to see if it is a Windows thing. About the string[255] - surely you don't mean using shortstrings inside my regular units[1]? The DLL source code only communicates to the caller via doubles, booleans and pchars (could be a few more, but not strings). I'm in the middle of kernel test builds at the moment, so forgive me if I'm not giving your posted example as much attention as it deserves. I was assuming that you'd written both the main program and the DLL, which would have been analogous to the program I checked (which also used the LCL etc.). If using pchars: is the program doing all storage allocation for these or is the DLL also allocating memory? Snippet - unit providing Business object has a uses clause calling my db unit that uses initialization/finalization to set up a single DBLayer object per application (or per library) and close it down. library dutchpostcode; ... [1] But I"m asking anyway - the world is starting to look flat here ;) 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). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DLL calling Firebird: slow and crashes at the end
On 26/09/2014 17:06, Mark Morgan Lloyd wrote:
> For Linux, cmem before HeapTrc before cthreads before Classes etc., in
> both main program and DLL. Otherwise play with String[255] etc.
Thanks. Currently not using cmem or heaptrc or cthreads.
(The "regular" GUI application using the db etc units doesn't either)
Currently trying to get my Linux VM going again (or reinstalling)...
will test it to see if it is a Windows thing.
About the string[255] - surely you don't mean using shortstrings inside
my regular units[1]? The DLL source code only communicates to the caller
via doubles, booleans and pchars (could be a few more, but not strings).
Snippet - unit providing Business object has a uses clause calling my db
unit that uses initialization/finalization to set up a single DBLayer
object per application (or per library) and close it down.
library dutchpostcode;
...
[1] But I"m asking anyway - the world is starting to look flat here ;)uses
Classes, businesslogic, postcodebulkcorrect, postcodedb, dutchaddress;
var
Address: TDutchAddress;
Business: TPostcodeBusiness;
...
function Address2Postcode(): PChar; {$IFDEF
MSWINDOWS}stdcall{$ELSE}cdecl{$ENDIF};
function CheckCitySpelling(City: PChar): boolean; {$IFDEF
MSWINDOWS}stdcall{$ELSE}cdecl{$ENDIF};
...
exports
Address2Postcode,
CheckCitySpelling,
...etc...
ValidateAddress;
{$R *.res}
begin
// Set up objects for use by our functions
Address:=TDutchAddress.Create;
Business:=TPostcodeBusiness.Create;
try
// nothing here
finally
Address.Free;
Business.Free;
end;
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DLL calling Firebird: slow and crashes at the end
Reinier Olislagers wrote: DLL creation newbie here; Windows; x86 FPC trunk. Going with the FPC programmer's guide, I wrote a DLL that looks up address data in a Firebird embedded db. Managed to get a console demo calling it running but: 1. It is slow to show output: no output for a while before showing the results of the address data calls to the dll. 2. It is slow to close as well. It hangs for a while and then Windows pops up a dialgo "dlldemo.exe has stopped working" etc. Firebird embedded log says it closed the connection while a user was connected, so I suspect my db code. Problem is, it works ok in my GUI code that uses units (no dlls). gdb dpesn't seem to show anything special. https://bitbucket.org/reiniero/postcode/src DLL source code: Source/dutchpostcode.lpr Demo program: Source/dlldemo.lpr Anything special/obvious I need to do? Enable multithreading? C memory manager? (FPC had a problem with Firebird embedded 2.5.3 but that was with client/server, not embedded+that has been fixed meanwhile) Advice (and requests on specific further info) welcome before I start wildly throwing switches? For Linux, cmem before HeapTrc before cthreads before Classes etc., in both main program and DLL. Otherwise play with String[255] etc. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] DLL calling Firebird: slow and crashes at the end
DLL creation newbie here; Windows; x86 FPC trunk. Going with the FPC programmer's guide, I wrote a DLL that looks up address data in a Firebird embedded db. Managed to get a console demo calling it running but: 1. It is slow to show output: no output for a while before showing the results of the address data calls to the dll. 2. It is slow to close as well. It hangs for a while and then Windows pops up a dialgo "dlldemo.exe has stopped working" etc. Firebird embedded log says it closed the connection while a user was connected, so I suspect my db code. Problem is, it works ok in my GUI code that uses units (no dlls). gdb dpesn't seem to show anything special. https://bitbucket.org/reiniero/postcode/src DLL source code: Source/dutchpostcode.lpr Demo program: Source/dlldemo.lpr Anything special/obvious I need to do? Enable multithreading? C memory manager? (FPC had a problem with Firebird embedded 2.5.3 but that was with client/server, not embedded+that has been fixed meanwhile) Advice (and requests on specific further info) welcome before I start wildly throwing switches? Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
