스트림이 start()에서 반환된 후 터미널은 lib 언로드를 시작한다고 생각합니다. 어떻게 작동합니까? 프로그램이 작동하고 환경을 파괴하기 시작합니까? 말도 안돼 루프에서 스크립트 스레드를 쫓지 않고 라이브러리에서 별도의 스레드를 실행하면 이제 정상적으로 완료할 수 있습니다.
스트림이 start()에서 반환된 후 터미널은 lib 언로드를 시작한다고 생각합니다. 어떻게 작동합니까? 프로그램이 작동하고 환경을 파괴하기 시작합니까? 말도 안돼 라이브러리에서 별도의 스레드를 시작하면 이제 정상적으로 완료할 수 있습니다.
문제는 스레드에서 동일한 문제가 발생하기 때문에 파괴해야 하는 개체가 많은 다른 프로세스(스레드)를 올바르게 종료할 수 없다는 것입니다. 그래서 위와 같이 간단한 예제를 만들어 보았는데 문제가 전혀 다른 것으로 판명되었습니다. 터미널이 종료점 DLL_PROCESS_DETACH 와 함께 올바르게 작동하지 않습니다.
TheXpert에서 제안한 대로 시도해 보겠습니다. 하지만 터미널이 DLL_PROCESS_DETACH에 관계없이 dll을 즉시 언로드한다는 사실은 아마도 터미널 오류일 것입니다.
더엑스퍼트 :
dll은 서비스 종료 직후에 (필연적으로) 언로드되지 않습니다 (틀릴 수 있음)
어쨌든 DLL_PROCESS_DETACH로 하는 일은 이미 너무 늦었습니다. 이 플래그를 설정하고 서비스가 종료될 때 명시적으로 호출되는 명시적 deinit 함수를 dll에서 만드십시오.
문제는 스레드에서 동일한 문제가 발생하기 때문에 파괴해야 하는 개체가 많은 다른 프로세스(스레드)를 올바르게 종료할 수 없다는 것입니다. 그래서 위와 같이 간단한 예제를 만들어 보았는데 문제가 전혀 다른 것으로 판명되었습니다. 터미널이 종료점 DLL_PROCESS_DETACH 와 함께 올바르게 작동하지 않습니다.
TheXpert가 제안한 대로 시도해 보겠습니다. 하지만 터미널이 DLL_PROCESS_DETACH에 관계없이 dll을 즉시 언로드한다는 사실은 아마도 터미널 오류일 것입니다.
팁 감사합니다 시도해보겠습니다.
그리고 dll이 별도의 스레드에 있다는 아이디어는 어디서 얻었습니까? 주기 조건에서 처리되지 않은 프로그램의 평범한 비상 종료가 있습니다.
그리고 DLL_PROCESS 프로세스에 dll이 연결/연결 해제될 때와 이 DLL_THREAD 프로세스에서 생성된 스레드가 생성/종료될 때 DllMain이 실행됩니다. 따라서 bool Detach는 dll 내부에 존재한다는 사실이 아니라 컴파일러가 최적화의 일부로 이를 제거할 수 있기 때문에 dll 의 수명 동안 모든 기능을 실행하는 동안 변경되지 않고 false와 동일하기 때문입니다. .
그리고 dll이 별도의 스레드에 있다는 아이디어는 어디서 얻었습니까? 주기 조건에서 처리되지 않은 프로그램의 평범한 비상 종료가 있습니다.
그리고 DLL_PROCESS 프로세스에 dll이 연결/연결 해제될 때와 이 DLL_THREAD 프로세스에서 생성된 스레드가 생성/종료될 때 DllMain이 실행됩니다. 따라서 bool Detach는 dll 내부에 존재한다는 사실이 아니라 컴파일러가 최적화의 일부로 이를 제거할 수 있기 때문에 dll 의 수명 동안 모든 기능을 실행하는 동안 변경되지 않고 false와 동일하기 때문입니다. .
어디에도 dll이 별도의 스레드에 있다고 말한 적이 없습니다. 빅트와 나 이야기를 나누었고, 우리는 우리가 무슨 말을 하는지 이해했다)) 충돌을 이해할 수 있다는 사실은 왜 DLL_PROCESS_DETACH의 플래그가 while 루프를 종료하기 위해 작동하지 않는지 명확하지 않습니다. DLL_THREAD의 경우 mql에서 전혀 사용할 수 없습니다 . 이것은 이 기사에 작성되었으며 실제로 작동하지 않는지 확인했습니다. 그러나 VS 컴파일러를 옵션으로 사용하면 재미있을 수도 있습니다. 유능한 담당자의 설명을 듣고 싶습니다. 추측이 아닙니다))
무엇을 원하세요?
당신, Fedoseev 등과 같은 무능한 사람들이 그들의 의견으로 버그와 디자인에 대한 토론에 끼어들지 않도록.
전체적으로 C++에서 MQL로 가져오고 C++에서와 동일하게 보이는 구성 및 메커니즘이 C++에서와 동일한 방식으로 작동하도록 합니다.
MQL이 C++의 완전한 아날로그가 되려면?
그리고 이것에 대해 징징거리고 콧물을 붓는 것을 그만 두십시오. 나는 그러한 "토론"에 대해 별도의 주제를 열었습니다.
너만 징징거려 그들이 그것을 어떻게 얻었는지, 별도의 언어와 별도의 지점에 대해.
너 자신과 동정하는 사람들과 거기에 노아를 위해 별도의 지점을 엽니 다.
터미널에서 mqd 파일을 강제로 해제하는 방법은 무엇입니까? 아니면 인터페이스에서 정기적으로 제거하는 방법이 있다면 더 좋습니까?
대략적인 질문이 무엇인지 짐작이 갑니다. 더 나은 재구성.
그러나 while은 다른 모든 프로세스를 추가로 완료한 후 아래 기능을 실행하기 위해 루프를 종료할 시간이 없습니다.
그리고 Fn() 함수 자체를 완성합니다.
DestroyFunction(); 이 예에서 테스트 역할을 합니다.
DLL 내용
프로그램 서비스의 내용.
_StopFlag 플래그에 대한 추가 지연은 도움이 되지 않습니다.
제 생각에는 서비스의 dll 초기화 해제에 문제가 있습니다. 해결하도록 도와주세요.
dll은 서비스 종료 직후에 (필연적으로) 언로드되지 않습니다 (틀릴 수 있음)
어쨌든 DLL_PROCESS_DETACH로 하는 일은 이미 너무 늦었습니다. 이 플래그를 설정하고 서비스가 종료될 때 명시적으로 호출되는 명시적 deinit 함수를 dll에서 만드십시오.
스트림이 start()에서 반환된 후 터미널은 lib 언로드를 시작한다고 생각합니다. 어떻게 작동합니까? 프로그램이 작동하고 환경을 파괴하기 시작합니까? 말도 안돼 루프에서 스크립트 스레드를 쫓지 않고 라이브러리에서 별도의 스레드를 실행하면 이제 정상적으로 완료할 수 있습니다.
스트림이 start()에서 반환된 후 터미널은 lib 언로드를 시작한다고 생각합니다. 어떻게 작동합니까? 프로그램이 작동하고 환경을 파괴하기 시작합니까? 말도 안돼 라이브러리에서 별도의 스레드를 시작하면 이제 정상적으로 완료할 수 있습니다.
문제는 스레드에서 동일한 문제가 발생하기 때문에 파괴해야 하는 개체가 많은 다른 프로세스(스레드)를 올바르게 종료할 수 없다는 것입니다.
그래서 위와 같이 간단한 예제를 만들어 보았는데 문제가 전혀 다른 것으로 판명되었습니다.
터미널이 종료점 DLL_PROCESS_DETACH 와 함께 올바르게 작동하지 않습니다.
TheXpert에서 제안한 대로 시도해 보겠습니다. 하지만 터미널이 DLL_PROCESS_DETACH에 관계없이 dll을 즉시 언로드한다는 사실은 아마도 터미널 오류일 것입니다.
dll은 서비스 종료 직후에 (필연적으로) 언로드되지 않습니다 (틀릴 수 있음)
어쨌든 DLL_PROCESS_DETACH로 하는 일은 이미 너무 늦었습니다. 이 플래그를 설정하고 서비스가 종료될 때 명시적으로 호출되는 명시적 deinit 함수를 dll에서 만드십시오.
팁 감사합니다 시도해보겠습니다.
문제는 스레드에서 동일한 문제가 발생하기 때문에 파괴해야 하는 개체가 많은 다른 프로세스(스레드)를 올바르게 종료할 수 없다는 것입니다.
그래서 위와 같이 간단한 예제를 만들어 보았는데 문제가 전혀 다른 것으로 판명되었습니다.
터미널이 종료점 DLL_PROCESS_DETACH 와 함께 올바르게 작동하지 않습니다.
TheXpert가 제안한 대로 시도해 보겠습니다. 하지만 터미널이 DLL_PROCESS_DETACH에 관계없이 dll을 즉시 언로드한다는 사실은 아마도 터미널 오류일 것입니다.
팁 감사합니다 시도해보겠습니다.
그리고 dll이 별도의 스레드에 있다는 아이디어는 어디서 얻었습니까? 주기 조건에서 처리되지 않은 프로그램의 평범한 비상 종료가 있습니다.
그리고 DLL_PROCESS 프로세스에 dll이 연결/연결 해제될 때와 이 DLL_THREAD 프로세스에서 생성된 스레드가 생성/종료될 때 DllMain이 실행됩니다. 따라서 bool Detach는 dll 내부에 존재한다는 사실이 아니라 컴파일러가 최적화의 일부로 이를 제거할 수 있기 때문에 dll 의 수명 동안 모든 기능을 실행하는 동안 변경되지 않고 false와 동일하기 때문입니다. .
그리고 dll이 별도의 스레드에 있다는 아이디어는 어디서 얻었습니까? 주기 조건에서 처리되지 않은 프로그램의 평범한 비상 종료가 있습니다.
그리고 DLL_PROCESS 프로세스에 dll이 연결/연결 해제될 때와 이 DLL_THREAD 프로세스에서 생성된 스레드가 생성/종료될 때 DllMain이 실행됩니다. 따라서 bool Detach는 dll 내부에 존재한다는 사실이 아니라 컴파일러가 최적화의 일부로 이를 제거할 수 있기 때문에 dll 의 수명 동안 모든 기능을 실행하는 동안 변경되지 않고 false와 동일하기 때문입니다. .
어디에도 dll이 별도의 스레드에 있다고 말한 적이 없습니다.
빅트와 나 이야기를 나누었고, 우리는 우리가 무슨 말을 하는지 이해했다))
충돌을 이해할 수 있다는 사실은 왜 DLL_PROCESS_DETACH의 플래그가 while 루프를 종료하기 위해 작동하지 않는지 명확하지 않습니다.
DLL_THREAD의 경우 mql에서 전혀 사용할 수 없습니다 . 이것은 이 기사에 작성되었으며 실제로 작동하지 않는지 확인했습니다.
그러나 VS 컴파일러를 옵션으로 사용하면 재미있을 수도 있습니다.
유능한 담당자의 설명을 듣고 싶습니다. 추측이 아닙니다))
제 생각에는 서비스의 dll 초기화 해제에 문제가 있습니다. 해결하도록 도와주세요.
그러나 while은 다른 모든 프로세스를 추가로 완료한 후 아래 기능을 실행하기 위해 루프를 종료할 시간이 없습니다.
그리고 Fn() 함수 자체를 완성합니다.
DestroyFunction(); 이 예에서 테스트 역할을 합니다.
DLL 내용
프로그램 서비스의 내용.
_StopFlag 플래그에 대한 추가 지연은 도움이 되지 않습니다.
이 얼마나 평범한 결말인가!
이러한 동작이 필요한 경우 DLL의 Fn 내부에서 별도의 FnStop 함수에 설정된 플래그에 의해 중지될 수 있는 주기로 별도의 스레드를 시작해야 하고 DLL_PROCESS_DETACH