Re: [fpc-pascal] is it possible to kill a thread from within fpc?
Mark Morgan Lloyd wrote: Dennis Poon wrote: I want to kill a thread created by my fpc program (not killing the entire process). I have to use an external win32 dll. I am already calling it from a separate thread but still, that dll something goes into an infinite loop which made my thread freezes. Are you absolutely sure that the loop is a coding error in the DLL, or is there any possibility that it's either because you're not calling it properly, because you've not initialised something properly, or because you're mistakenly allocating memory using a heap manager in the DLL and then releasing it in the main program or vice-versa? Noting everything that Jonas has said, and pointing out that there's been extensive discussion in the past relating to even calling Suspend from inside the thread's own code, I'd point out that it's fairly common practice for programs such as Firefox to launch a separate process (not thread) to handle e.g. an instance of the Flash player. Is this something you could do, or do you have to have fine-grained control of multiple subroutines in the DLL? It am quite sure it is the dll's problem because the problem happens at 11pm everyday only. Nothing in my program has anything related to that time. The dll is a brokerage firm's order placing system. 11pm is when the market closes so probably the dll has something done at that time that loops forever. Using a separate process to call it is possible but exchanging data between my program and that process will slow down entire communication and time sensitivity is required for online trading program. The supplier of the dll is quite irresponsive to questions or bug report. Anyway, thanks for all your comments. Dennis ___ 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
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
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 Im 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: 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 Im 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: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: 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
