Event stream. How to control and make the event idle ? (+ solved) - page 2
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Yedelkin:
Accordingly, it's still unclear about how often user events should be sent so that they don't overflow the terminal event queue...
I can't find an answer to the question: how does an event queue overflow affect RAM size? If the event queue becomes full, where do the events that overflowed the queue go? Is part of the RAM, reserved for those events that happened to be "out of history", freed up?
Maybe my questions are not terminologically correct, but (I hope) they capture the essence of the problem.
The queue is dynamic and grows by necessity.
But at a certain limit, new events are discarded as it is clear that there is no point in loading the queue further.
I can tell right away that you haven't read my posts.
Why didn't you "read it"? You solved your problem, I'm trying to solve mine, of a different kind. When I read the discussion, I didn't find an answer to my questions.
You did not answer my main question. :/ That's exactly the "see at a glance" :)
The queue is dynamic and grows as needed.
But at a certain limit, new events are discarded, because it is clear that there is no point in loading the queue further.
OK, the queue is "dynamic". Increases to some "certain" limit. But why nobody can give an answer to a seemingly simple question: how does event queue overflow affect memory size?
Follow-up questions: How much RAM is required to "maintain" an overflowed event queue? If "at a certain limit, new events are discarded", is the RAM previously allocated for these discarded events freed?
Purpose of the questions: to understand how the flow of user events can increase (increases) the amount of RAM consumed by the terminal.
If the event queue is full, where do the events that overflowed the queue go? Is part of the RAM reserved for those events that are "out of history" freed up?
Maybe my questions are not terminologically correct, but (I hope) they convey the essence of the problem.
The section says Program Execution that new events are discarded when the queue overflows:
The client terminal sends the occurring events to the appropriate open graphs. Events can also be generated by charts (chart events) or mql5 programs (custom events). Generation of events of creating and deleting graphical objects on a chart can be enabled or disabled by setting the CHART_EVENT_OBJECT_CREATE and CHART_EVENT_OBJECT_DELETE properties of a chart. Each mql5-program and each chart has its own queue of events, where all new events are stored.
The program receives events only from the chart, on which it is running. All events are processed one by one in the order of receipt. If there is already an event NewTick in the queue or if this event is in the processing state, a new event NewTick is not placed in the queue of the mql5-program. Similarly, if the queue of the mql5-program already contains the ChartEvent event or the event is being processed, a new event of this type is not placed in the queue.
Event queues have a limited, but sufficient size, so the queue overflow for a correctly written program is unlikely. When the queue overflow occurs, new events are discarded without being queued.
It is highly discouraged to use infinite loops to process events. The only exception to this rule are scripts that handle a single Start event.
Libraries do not handle any events.
Why didn't you "read it"? You solved your problem, I'm trying to solve mine, of a different kind. When I read the discussion, I didn't find an answer to my questions.
You did not answer my main question. :/ I could definitely "see right away" :)
Your question "what's the approximate frequency at which user events should be sent, so they don't overflow the queue".
My answer on the first page is "with the frequency of OnChartEvent calls".
That is, one event is one OnChartEvent. There should not be more than two events in between.
That's all the maths.
Once again, read the first page. I showed how to avoid accumulation of user events when terminal event is processed instead of user event. It's as simple as that.
Purpose of the questions: to understand how a thread of user events can increase (increase) the size of RAM consumed by the terminal.
Why? Well, yes, it does. The price of the question is a few megabytes.
That's not the problem, or not really the problem.
The section says Programme Execution, which...:
1. the Handbook section has undergone significant changes.
1.1 For example, it used to be:"The client terminal puts all occurring events into a common queue. Thus events are processed one after another in order of arrival. The exception is NewTick event. If there is already such an event in the queue or if this event is being processed, a new NewTick event is not placed in the queue".
Now:"The program receives events only from the chart it is running on. All events are processed one after the other in the order they are received. If there is already an event NewTick in the queue or this event is in the processing state, a new event NewTick is not placed in the queue of the mql5-program. Similarly, if there is already an event ChartEvent in the queue of mql5-program or such an event is being processed, a new event of this type is not placed in the queue.
As the saying goes, "See the difference". You should at least be warned. :/ This change fundamentally changes the way we work with custom events.
1.2. Next. The principle of discarding events is turned upside down. It used to be, "The event queue has a limited size. When the queue becomes full, old events are deleted without being processed to make room for new incoming events".
Now: "When the queue is full, new events are discarded without being queued". As they say, thank you: we lose the most relevant user events.
2. The quoted section of the Handbook does not answer my basic questions: How does event queue overflow affect RAM size? How much RAM is required to "maintain" an overflowing event queue? If "at a certain limit, new events are discarded", is the RAM previously allocated for those discarded events freed up?
TheXpert:
Purpose of the questions: to understand how a thread of user events can increase (increase) the size of RAM consumed by the terminal.
Why? Well, yes, it does. The question is worth several megabytes.
2. The quoted section in the Handbook does not answer my main questions: How does event queue overflow affect RAM size? How much RAM is required to "maintain" an overflowing event queue? If "at a certain limit, new events are discarded", is the RAM previously allocated for those discarded events freed up?
If such problems arise, things are very bad. I think an overflowing event queue is the last place to look for memory problems.
If an event is discarded, then it's just not being put in the queue. The memory is not growing.