-
Content Count
246 -
Joined
-
Last visited
-
Days Won
11
Posts posted by Primož Gabrijelčič
-
-
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?
- 1
-
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.
- 1
-
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.
- 1
-
16 minutes ago, PatV said:Is it possible I have a race condition
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
-
1 hour ago, Der schöne Günther said:https://quality.embarcadero.com/browse/RSP-23466 reports that OmniThreadLibrary is also affected. Can somebody confirm that?
"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.
-
Delphi 10.3.2, IDE Fix Pack 6.4.4
When I close a project with File, Close All, I get this error:
This happens with all projects.
Startup Layout.dst attached.
-
-
Works great! Thank you for a prompt fix! (And thank you for IDEFixPack!)
- 1
-
I was wrong - it is CodeGenMod.Win32.VirtFinalSealed. When I disable it, the project can be rebuilt again.
- 1
-
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.
-
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?
- 1
-
-
Indeed, a workaround is not a problem. The bug in itself is, though 😞
Canceling a scheduled task
in OmniThreadLibrary
Posted
Sorry, I did not mean to imply that. You can definitely use TaskConfig.CancelWith and then check task.CancellationToken in your thread.