클라이언트 단말은 발생한 이벤트를 해당 오픈 차트로 전송합니다. 이벤트는 차트( 차트 이벤트 ) 또는 mql5 프로그램( 사용자 이벤트 )에 의해 생성될 수도 있습니다. 차트에서 그래픽 개체를 생성 및 삭제하기 위한 이벤트 생성은 차트 속성 CHART_EVENT_OBJECT_CREATE 및 CHART_EVENT_OBJECT_DELETE 를 설정하여 활성화 및 비활성화할 수 있습니다. 각 mql5 프로그램과 각 차트에는 새로 도착하는 모든 이벤트가 추가되는 자체 이벤트 대기열이 있습니다.
프로그램은 실행 중인 차트에서만 이벤트를 수신합니다. 모든 이벤트는 수신된 순서대로 하나씩 처리됩니다. 큐에 이미 NewTick 이벤트가 있거나 이 이벤트가 처리 중인 경우 새 NewTick 이벤트는 mql5 프로그램의 큐에 넣지 않습니다. 마찬가지로, ChartEvent 이벤트가 이미 mql5 프로그램 의 대기열에 있거나 이러한 이벤트가 처리 중인 경우 이 유형의 새 이벤트는 대기열에 포함되지 않습니다.
이벤트 큐는 제한적이지만 충분한 크기를 가지고 있으므로 잘 작성된 프로그램이 큐를 오버플로할 가능성은 거의 없습니다. 대기열이 가득 차면 대기열에 넣지 않고 새 이벤트가 삭제됩니다.
이벤트 처리에 무한 루프를 사용하지 않는 것이 좋습니다. 이 규칙의 유일한 예외는 단일 시작 이벤트를 처리하는 스크립트입니다.
1.1. 예를 들어, " 클라이언트 터미널은 모든 새로운 이벤트를 공통 큐에 넣습니다. 따라서 이벤트는 도착한 순서대로 차례로 처리됩니다.예외는 NewTick 이벤트입니다. 이미 그러한 이벤트가 있는 경우 대기열의 이벤트 또는 이 이벤트가 처리 상태에 있는 경우 새 이벤트 NewTick이 대기열에 포함되지 않습니다 .
Now: " 프로그램은 실행된 차트에서만 이벤트를 수신합니다. 모든 이벤트는 도착한 순서대로 차례로 처리됩니다. 큐에 이미NewTick 이벤트가 있거나 이 이벤트가 처리 상태인 경우 그런 다음 새 NewTick 이벤트가 mql5 프로그램 대기열에 추가됩니다. 마찬가지로 ChartEvent 이벤트가 이미 mql5프로그램 의 대기열에 있거나 이러한 이벤트가 처리 중인 경우 이 유형의 새 이벤트는 대기열에 추가되지 않습니다 .
"차이를 느껴라"라는 말이 있듯이. 적어도 그들은 경고했을 것입니다. :/ 이 변경은 사용자 이벤트 작업에 대한 접근 방식을 근본적으로 바꿉니다. 팬케이크.
1.2. 더 나아가. 이벤트를 버리는 원칙은 거꾸로 되어 있습니다. 이전에는 "이벤트 큐의 크기가 제한되어 있습니다. 큐가 가득 차면 새로 도착하는 이벤트를 위한 공간을 만들기 위해 기존 이벤트를 처리 하지 않고 삭제합니다."
현재: "대기열이 오버플로되면 대기열에 넣지 않고 새 이벤트가 삭제됩니다." 감사합니다. 가장 관련성이 높은 사용자 이벤트를 잃게 됩니다.
2. 핸드북의 인용된 섹션은 내 주요 질문에 대답하지 않습니다 . 이벤트 대기열의 오버플로가 RAM 크기에 어떤 영향을 줍니까? 오버플로 이벤트 대기열을 "보유"하려면 얼마나 많은 RAM이 필요합니까? "특정 제한에서 새 이벤트가 폐기됨"인 경우 이러한 폐기된 이벤트에 대해 더 일찍 할당된 RAM이 해제됩니까?
2. 핸드북의 인용된 섹션은 내 주요 질문에 대답하지 않습니다 . 이벤트 대기열의 오버플로가 RAM 크기에 어떤 영향을 줍니까? 오버플로 이벤트 대기열을 "보유"하려면 얼마나 많은 RAM이 필요합니까? "특정 제한에서 새 이벤트가 폐기됨"인 경우 이러한 폐기된 이벤트에 대해 더 일찍 할당된 RAM이 해제됩니까?
그러한 문제가 발생하면 모든 것이 매우 나쁩니다. 오버플로 이벤트 큐가 메모리 문제를 찾는 마지막 장소라고 생각합니다.
Yedelkin :
따라서 사용자 이벤트가 터미널의 이벤트 대기열을 넘지 않도록 얼마나 자주 사용자 이벤트 를 보내야 하는지는 아직 명확하지 않습니다...
질문에 대한 답을 찾을 수 없습니다. 이벤트 대기열의 오버플로가 RAM 크기에 어떤 영향을 줍니까? 이벤트 큐가 가득 차면 큐를 넘친 이벤트는 어디로 가나요? "기록에서 벗어난" 것으로 판명된 이벤트를 위해 예약된 RAM의 일부가 해제되었습니까?
내 질문이 용어상 일관성이 없을 수도 있지만 (나는) 문제의 본질을 전달하기를 바랍니다.
대기열은 동적이며 필요에 따라 늘어납니다.
그러나 특정 제한에서 새 이벤트는 폐기됩니다. 왜냐하면 대기열을 더 이상 로드할 의미가 없다는 것이 분명하기 때문입니다.
내 글을 읽지 않은 것이 분명합니다.
왜 "읽지 않았어"? 당신은 당신의 문제를 해결했습니다, 나는 다른 계획의 내 문제를 해결하려고합니다. 토론을 읽을 때 내 질문에 대한 답을 찾지 못했습니다.
당신은 내 주요 질문에 대답하지 않았습니다. :/ 이것은 정확히 "바로 보이는" 것입니다 :)
대기열은 동적이며 필요에 따라 늘어납니다.
그러나 특정 제한에서 새 이벤트는 폐기됩니다. 왜냐하면 대기열을 더 이상 로드할 의미가 없다는 것이 분명하기 때문입니다.
큐는 "동적"입니다. 특정 "특정" 한도까지 증가합니다. 그러나 겉보기에 단순한 질문에 왜 아무도 대답을 하지 못합니까? 이벤트 큐의 오버플로가 RAM 크기에 어떤 영향을 미칠 까요?
후속 질문: 오버플로 이벤트 대기열을 "포함"하려면 얼마나 많은 RAM이 필요합니까? "특정 제한에서 새 이벤트가 폐기됨"인 경우 이러한 폐기된 이벤트에 대해 더 일찍 할당된 RAM이 해제됩니까?
질문의 목적은 사용자 이벤트 스트림이 터미널에서 사용하는 RAM 크기를 어떻게 증가(증가)시킬 수 있는지 이해하는 것입니다.
이벤트 큐가 가득 차면 큐를 넘친 이벤트는 어디로 가나요? "기록에서 벗어난" 것으로 판명된 이벤트를 위해 예약된 RAM의 일부가 해제됩니까?
내 질문이 용어상 일관성이 없을 수도 있지만 (나는) 문제의 본질을 전달하기를 바랍니다.
Executing Programs 섹션은 큐가 오버플로되면 새 이벤트가 삭제 된다고 말합니다.
클라이언트 단말은 발생한 이벤트를 해당 오픈 차트로 전송합니다. 이벤트는 차트( 차트 이벤트 ) 또는 mql5 프로그램( 사용자 이벤트 )에 의해 생성될 수도 있습니다. 차트에서 그래픽 개체를 생성 및 삭제하기 위한 이벤트 생성은 차트 속성 CHART_EVENT_OBJECT_CREATE 및 CHART_EVENT_OBJECT_DELETE 를 설정하여 활성화 및 비활성화할 수 있습니다. 각 mql5 프로그램과 각 차트에는 새로 도착하는 모든 이벤트가 추가되는 자체 이벤트 대기열이 있습니다.
프로그램은 실행 중인 차트에서만 이벤트를 수신합니다. 모든 이벤트는 수신된 순서대로 하나씩 처리됩니다. 큐에 이미 NewTick 이벤트가 있거나 이 이벤트가 처리 중인 경우 새 NewTick 이벤트는 mql5 프로그램의 큐에 넣지 않습니다. 마찬가지로, ChartEvent 이벤트가 이미 mql5 프로그램 의 대기열에 있거나 이러한 이벤트가 처리 중인 경우 이 유형의 새 이벤트는 대기열에 포함되지 않습니다.
이벤트 큐는 제한적이지만 충분한 크기를 가지고 있으므로 잘 작성된 프로그램이 큐를 오버플로할 가능성은 거의 없습니다. 대기열이 가득 차면 대기열에 넣지 않고 새 이벤트가 삭제됩니다.
이벤트 처리에 무한 루프를 사용하지 않는 것이 좋습니다. 이 규칙의 유일한 예외는 단일 시작 이벤트를 처리하는 스크립트입니다.
라이브러리 는 이벤트를 처리하지 않습니다.
왜 "읽지 않았습니까"? 당신은 당신의 문제를 해결했고 나는 다른 계획의 내 문제를 해결하려고 노력하고 있습니다. 토론을 읽을 때 내 질문에 대한 답을 찾지 못했습니다.
당신은 내 주요 질문에 대답하지 않았습니다. :/ 이것은 정확히 "바로 보이는" 것입니다 :)
귀하의 질문은 "대기열이 오버플로되지 않도록 사용자 이벤트 를 대략 얼마나 자주 발송해야 하는지"입니다.
첫 번째 페이지의 내 대답은 "OnChartEvent 호출 빈도"입니다.
즉, 하나의 이벤트 - 하나의 OnChartEvent입니다. 그 사이에 2개 이상의 이벤트가 있어서는 안 됩니다.
그게 수학의 전부입니다.
다시, 첫 페이지를 읽으십시오. 사용자 이벤트 대신 터미널 이벤트가 처리될 때 사용자 이벤트가 누적되는 것을 방지하는 방법을 보여주었습니다. 모든 것이 간단합니다.
질문의 목적은 사용자 이벤트 스트림이 터미널에서 소비하는 RAM 크기를 어떻게 증가(증가)시킬 수 있는지 이해하는 것입니다.
무엇 때문에? 예, 증가합니다. 문제의 가격은 몇 메가 바이트입니다.
그게 문제가 아니거나 전혀 문제가 되지 않습니다.
섹션은 다음을 수행하는 프로그램을 실행 합니다.
1. 핸드북 섹션이 크게 변경되었습니다.
1.1. 예를 들어, " 클라이언트 터미널은 모든 새로운 이벤트를 공통 큐에 넣습니다. 따라서 이벤트는 도착한 순서대로 차례로 처리됩니다. 예외는 NewTick 이벤트입니다. 이미 그러한 이벤트가 있는 경우 대기열의 이벤트 또는 이 이벤트가 처리 상태에 있는 경우 새 이벤트 NewTick이 대기열에 포함되지 않습니다 .
Now: " 프로그램은 실행된 차트에서만 이벤트를 수신합니다. 모든 이벤트는 도착한 순서대로 차례로 처리됩니다. 큐에 이미 NewTick 이벤트가 있거나 이 이벤트가 처리 상태인 경우 그런 다음 새 NewTick 이벤트가 mql5 프로그램 대기열에 추가됩니다. 마찬가지로 ChartEvent 이벤트가 이미 mql5 프로그램 의 대기열에 있거나 이러한 이벤트가 처리 중인 경우 이 유형의 새 이벤트는 대기열에 추가되지 않습니다 .
"차이를 느껴라"라는 말이 있듯이. 적어도 그들은 경고했을 것입니다. :/ 이 변경은 사용자 이벤트 작업에 대한 접근 방식을 근본적으로 바꿉니다. 팬케이크.
1.2. 더 나아가. 이벤트를 버리는 원칙은 거꾸로 되어 있습니다. 이전에는 "이벤트 큐의 크기가 제한되어 있습니다. 큐가 가득 차면 새로 도착하는 이벤트를 위한 공간을 만들기 위해 기존 이벤트를 처리 하지 않고 삭제합니다."
현재: "대기열이 오버플로되면 대기열에 넣지 않고 새 이벤트가 삭제됩니다." 감사합니다. 가장 관련성이 높은 사용자 이벤트를 잃게 됩니다.
2. 핸드북의 인용된 섹션은 내 주요 질문에 대답하지 않습니다 . 이벤트 대기열의 오버플로가 RAM 크기에 어떤 영향을 줍니까? 오버플로 이벤트 대기열을 "보유"하려면 얼마나 많은 RAM이 필요합니까? "특정 제한에서 새 이벤트가 폐기됨"인 경우 이러한 폐기된 이벤트에 대해 더 일찍 할당된 RAM이 해제됩니까?
TheXpert :
질문의 목적은 사용자 이벤트 스트림이 터미널에서 소비하는 RAM 크기를 어떻게 증가(증가)시킬 수 있는지 이해하는 것입니다.
무엇 때문에? 예, 증가합니다. 문제의 가격은 몇 메가 바이트입니다.
2. 핸드북의 인용된 섹션은 내 주요 질문에 대답하지 않습니다 . 이벤트 대기열의 오버플로가 RAM 크기에 어떤 영향을 줍니까? 오버플로 이벤트 대기열을 "보유"하려면 얼마나 많은 RAM이 필요합니까? "특정 제한에서 새 이벤트가 폐기됨"인 경우 이러한 폐기된 이벤트에 대해 더 일찍 할당된 RAM이 해제됩니까?
그러한 문제가 발생하면 모든 것이 매우 나쁩니다. 오버플로 이벤트 큐가 메모리 문제를 찾는 마지막 장소라고 생각합니다.
이벤트가 삭제되면 단순히 대기열에 포함되지 않습니다. 메모리가 증가하지 않습니다.