Sonjli

Ok, this is my last chance... after this you must wait for @Primož Gabrijelčič Try something like this: procedure ProcessMessages; var Msg: TMsg; begin while integer(PeekMessage(Msg, 0, 0, 0, PM_REMOVE)) <> 0 do begin TranslateMessage(Msg); DispatchMessage(Msg); end; end; ... FKeepAlive.Stop; repeat ProcessMessages; until FKeepAlive.Terminate(1000); ...

Hi, I am pretty sure the problem is related to this: http://www.omnithreadlibrary.com/book/chap05.html#introotl-messagelooprequired-console Regards, Eddy

The only problem I know about console apps is about "omni messaging system". Look at documentation http://www.omnithreadlibrary.com/book/chap05.html#introotl-messagelooprequired-console Maybe after 5 seconds the parallel timer is not terminated. Try this: destructor TjBASEComm.Destroy; begin if Assigned(FKeepAlive) then try FKeepAlive.Stop; FKeepAlive.Terminate; FKeepAlive.WaitFor; // This wait until the task is REALLY terminated. If it is stuck then the problem is elsewhere except end; try FConn.Free; except end; inherited; end; There is also a doubt about "FConn.SendStr('')": what does it do? Regards, Eddy

Hi, I think your problem is FConn. It seems a class field, and maybe it is destroyed before the timer ends? Regards, Eddy

No, it's "Pipeline" of OmniThreadLibrary

Hello, I am trying to read from a tcp socket some data and elaborate it in a pipeline. The pipeline should do something like this: Stage 1: polling the tcp socket and write the list of bytes in Output Stage 2: read output and make some calculation with bytes (I need to know when a packet starts and ends) The problem is that in the second stage I receive a list of simple "numbers" (a list of bytes) not continously. I mean that the bytes arrive in groups, but I need to save them in a global array to make my decisions. Questions: 1. Is the pipeline the right choice? 2. How can I use a global array inside a Pipeline? (I can't use SetParameter as in ITaskController) Thanks in advance Eddy

It's hard to reproduce, yes I understand your pov... I'll try

Ok, thank you as usual. So, I have this strange behavoiur: The task receiving messages sometimes slow very down, and I can see 30/40 messages queued from the "external" thread, but only one elaboration of my task loop. So in this situation the queue risks to be full very quickly (1000 messages I read in docs). But I don't know why this happens... a loop too thight?

Hello, I am trying to start communication between two threads. The first thread is not mine, it come from an external component library (always Delphi). This component has an event "OnSomethingHappens" that fires in a separate thread. So, in this event I use the OTL Communication system. For example: lMyTask.Comm.Send(WM_MYMESSAGE, MyObject); In my task I do a simple loop like this: while Task.Comm.Receive(lMsg) do begin if lMsg.MsgID = WM_MYMESSAGE then etc. But watching at OTL demos I see that you do somthing like this: repeat case DSiWaitForTwoObjects(task.TerminateEvent, task.Comm.NewMessageEvent, false, task.Param['Delay']) of WAIT_OBJECT_1: begin while task.Comm.Receive(msgID, msgData) do begin if msgID = MSG_CHANGE_MESSAGE then msg := msgData; end; end; WAIT_TIMEOUT: task.Comm.Send(0, msg); else break; //repeat end; until false; Sorry for my ignorance but I don't understand why you use the DSiWaitForTwoObjects and what it means. As I am having some problems in my loop, I think they are related to this use case... so can you explain, please? Thanks again, Eddy

To kill the "childs" I do this: FCancellationToken.Signal; FPlugsGroup.WaitForAll; FPlugsGroup is the group for the childs

Don't sorry, it's me the one bothering... The OnTerminated is not called even when everything goes right. The strange thing is that the messaging system (task.comm and OnMessage) is perfectly ok.

Thank you very much for the fast response. Naturally, this bug don't comes with debugging but in real production from customer... I'll try the logging solution. Thanks again. ps: any idea for the OnTerminated event in the child task?

Hello, I have a task which dies unexpectedly and I don't know how to check this situation. I know for sure it is something related with my software. I added all the "try\except" needed to catch the exception but the task dies the same. The task (I will call it "Child") is created by a MainTask, but when the child dies, the father continues without problems. The Main Task creates a lot of this Child. Every child is good isolated. There are not concurrent resources used between them. The child task contains an infinite loop testing the task.terminated. The child task is added to a TaskGroup and I tested that when it "dies bad" also disappear from TaskGroup. The "OnTerminated" on child does not trigger in this scenario. The child thread never call the OnTerminated, neither in "good termination" case. I don't know why. I don't know how to catch the "FatalException" of the child. How can I test this? I don't know how many other infos you need. Thanks, Eddy

Yes, in my tests I found some strange behaviours within the omnitask and reference counting, very hard to explain and to test. But after days of pain I found the problem, and I am pretty sure it is not related to Omni or Spring. I am writing a microservices framework with mqtt using a library with some problems with threading... Thanks and keep up the good job Eddy

Hello, I will always repeat that without mmx my team could be 5 times slower... thanks for this diamond 🙂 I only have a small glitch: when I drag a generic Interface (i.e.: IMyInterface<TDummyType>) over a concrete class that I want to implement that generic Interface, then mmx don't work. It says that it can't parse the class. Can this be solved? Thanks again, Eddy