Primož Gabrijelčič

I'm usually doing such logging in a manner similar to the one Kas Ob. presented. I establish a logging queue. Usually a TOmniQueue as it does not require locking. Then I create a logging thread. In essence it does just: while logQueue.Get(msg) do Log(ms); Each part of the program that wants to log, just creates a `msg` record containing whatever info you need to perform the logging (message, severity, timestamp, target file ...) and pushes it into the logging queue. That's it.

My book Hands-On Design Patterns with Delphi covers a Pipeline pattern which I fully implemented in PPL. It may give you some ideas on how to approach your problem. The source code is freely available on GitHub.

Sorry, I did not mean to imply that. You can definitely use TaskConfig.CancelWith and then check task.CancellationToken in your thread.

As you have correctly established, stopping a thread is cooperative. Thread owner can only nicely ask the worker thread to please stop, but if the worker thread keeps working, the owner can do nothing about that (short of calling TerminateThread, but that is really a bad idea). Passing cancellation token to the worker is a good approach. You can just capture `FCancel` in your code: .Execute( procedure begin OnStatsRefresh(TGITSVCMiddleWareRuntimeInfo.RunningStatistics(FCancel), FCancel); end); I don't which of your methods is slow - `RunningStatistics` or `OnStatsRefresh` so I passed `FCancel` to both.

Beautiful, thank you!

Can you put built packages somewhere where we can download them, pretty please?

OTL should work perfectly fine with the 64-bit Windows compiler. What error are you getting and which Delphi version are you using?

FastMM is not required for OmniThreadLibrary. You can use any memory manager. Mandelbrot generates the image on double-click. It does behave strangely, though, I agree. I'll look into that.

You are compiling 32-bit version but your settings (path) point to 64-bit dcu. Maybe you can just try to rebuild instead of recompile?

It depends on how lBroadcaster's OnReceive callback is implemented. If that event is called in the context of the "inside thread", then yes - this locking is necessary and it is correctly implemented.

Yes. The answer does not depend on the rest of the statement 😞 Thread pool does not get destroyed unless you destroy it in the code. A thread from a thread pool does not get destroyed while it is running your code. You can process thread pool events to be informed when a thread will be destroyed: http://www.omnithreadlibrary.com/book/chap07.html#lowlevel-threadpool-monitoring

"This also appears to affect OmiThreadLibrary" without any accompanying code does not mean anything. It was probably a moon phase, or Mercury in retrograde, not OTL.

OK, now for reals 🙂 (Sorry for the wrong answer before. You did not provide a test project so I did not open my Delphi at all and just guessed at the answer.) As the SetThreadDataFactory doesn't yet support anonymous method factory, your best bet is to use a singleton to store parameters and provide a factory. Just a sketch of a solution: type TThreadFactory = class public class var Handle: THandle; class function Make: IInterface; end; FConnectionPool := CreateThreadPool('Connection pool'); TThreadFactory.Handle := aHandle; FConnectionPool.SetThreadDataFactory(TThreadFactory.Make);

Yeah, as it turned out, SetThreadDataFactory doesn't yet support an anonymous method factory. Have to fix that ... 😞 I'll write a better answer soon (today).

Ah, SetThreadDataFactory actually doesn't support taking an anonymous function as an argument. An oversight that I should fix in a future. So - pass a normal function or method name to SetThreadDataFactory, not an anonymous method. (And I will amend my answer to your previous question on that topic.)

You can just use aConfig inside the anonymous function. Compiler will capture it for you. function TFConfig.CreateThreadPool(aHandle : THandle ; aConfig : rConnectionConfig ; aValue: string) : iOmniThreadPool; begin result := otlThreadPool.CreateThreadPool(aValue); result.MaxExecuting := result.NumCores; result.SetThreadDataFactory ( function: IInterface begin result:= MakeInterface(aHandle, aConfig); // implement MakeInterface end ); end;

Sorry, until you get us a reproducible test case, I cannot tell you anything.

Just use any of the mechanisms for sending data to the main thread (Task.Comm.Send, Task.Invoke). Or standard Delphi mechanisms (TThread.Queue). Or am I missing something?

This works: program Project191; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, OtlCommon; type TpDataType = (dtNone, dtInteger, dtDateTime, dtString, dtBlob); rParameter= record Field : string; Value : Variant; AsValue : TpDataType; end; TParameters = TArray<rParameter>; var params, params2: TParameters; ov: TOmniValue; begin SetLength(params, 2); params[0].Field := 'a'; params[0].Value := 1; params[0].AsValue := dtInteger; params[1].Field := 'b'; params[1].Value := Now; params[1].AsValue := dtDateTime; ov := TOmniValue.FromArray<rParameter>(params); params2 := ov.ToArray<rParameter>; end. You will have to convert 'array of rParameter' to 'TArray<rParameter>'. TOmniValue has special support (FromArray, ToArray) for the latter but not for the former.

My approach: https://github.com/gabr42/GpDelphiUnits/blob/master/src/GpCommandLineParser.pas

IDE Fix Pack 6.4.3 breaks compilation in Rio 10.3.2 for our flagship application. After compile or rebuild, I get [dcc32 Fatal Error] FAB .gRPC . pas ( 265): F2084 Internal Error: AV0D0F16E4(0D080000)-R0000000C-0 Wihout IDE Fix Pack, compilation works fine. Any suggestions?

Works great! Thank you for a prompt fix! (And thank you for IDEFixPack!)

I was wrong - it is CodeGenMod.Win32.VirtFinalSealed. When I disable it, the project can be rebuilt again.

What was the patch that did not get applied in 6.4.2 because of the change in 10.3.2? I'm pretty sure that everything worked fine with 6.4.2.

Hi all, Somehow I think that the following code should compile, but it does not. It looks like the compiler uses the wrong `TCallback` definition when resolving the property. Am I correct or did I miss something and I'm just stupid? program Project184; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils; type TCallback = reference to procedure (value: int64); TRunner = class public type TCallback = reference to procedure; strict private FOnCallback: TCallback; public procedure Run; property OnCallback: TCallback read FOnCallback write FOnCallback; end; procedure TRunner.Run; begin OnCallback(); // <-- E2035 Not enough actual parameters end; begin end. Delphi 10.3.1, in case this is a regression bug.