Asynchronous and multi-threaded programming in MQL - page 24

 
Roman:

I didn't study to be a programmer, I'm learning everything myself, so don't kick me to the curb ))

Me neither. I have a different profession. Programming is just a tool, like a hammer).

Creating DLL for MKL - there's absolutely standard DLL, no special features. The rest is pure C++, or pure C# if you like.

Teaching C++ or Sharp is just beyond me, but there's wagons of literature, at any level.

There's an article on MKL about creating a simple DLL, can't say anything about it being informative. Yes, and Google to help with the query - C++ DLL creation.

By the way, speaking of the entry point and so on. In Visual Studio you create a DLL project and everything you need is created by yourself, just don't touch it with your hands). Well, while the interaction functions, threads etc. are up to you. - are up to you. This is C++, no such features associated specifically with the DLL.

SZY The best way to learn anything is for you to solve a specific task. It wasn't even invented by me).

 
Yuriy Asaulenko:

Neither do I. I have a different profession. Programming is just a tool, like a hammer).

Creating dlls for MKL - absolutely standard dlls there, no special features. The rest is pure C++, or pure C# if you like.

Teaching C++ or Sharp is just beyond me, but there's wagons of literature, at any level.

There's an article on MKL about creating a simple DLL, can't say anything about it being informative. Yes, and Google to help with the query - C++ DLL creation.

By the way, speaking of the entry point and so on. In Visual Studio a DLL project is created and everything you need is created by itself, just don't touch it with your hands). Well, while the interaction functions, threads etc. are up to you. - are up to you. This is C++; there are no such features associated specifically with the DLL.

Yes, I can write the dll itself, with an empty entry point))
But the information on the entry point is nowhere, just tinny, no google gives, no literature similar ((.
I have exactly a problem with entry point, as you write interaction functions, initialization, memory allocation, threads, deinitialization, etc.
I know that all this is implemented in a switch at the entry point and that's it, a deadlock)).
I don't even know what to look for to study.

 
Roman:

Yes I can write the dll itself, with an empty entry point ))
But the information on the entry point is nowhere, just hell, neither google nor similar literature ((
I have exactly a problem with entry point, as you write interaction functions, initialization, memory allocation, threads, deinitialization, etc.
I know that all this is implemented in a switch at the entry point and that's it, a deadlock)).
I don't even know what to look for to study.

Do you assume I know anything about the entry point? It's not the king's business). There is only one unique function in the DLL that defines it

// dllmain.cpp: определяет точку входа для приложения DLL.
#include "stdafx.h"

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                                         )
{
        switch (ul_reason_for_call)
        {
        case DLL_PROCESS_ATTACH:
        case DLL_THREAD_ATTACH:
        case DLL_THREAD_DETACH:
        case DLL_PROCESS_DETACH:
                break;
        }
        return TRUE;
}

There's no need to understand it). In the future, in most cases there is no need to use this when writing and operating the DLL. The main thing is not to touch it with your hands).

 
Yuriy Asaulenko:

Do you suppose I know anything about the entry point? It's not the king's business). There is only one unique function in the DLL that defines it

There's no need to understand it). In the future, in most cases there is no need to use this when writing and operating the DLL. The main thing is not to touch it with your hands).

No, you need to understand it, you've written your own sequence of actions, so I thought you know it well.
In this input point all actions,functions initialization,memory allocation, thread creation, deinitialization, etc. are performed.
At least what to read on this topic?

Forum on trading, automated trading systems and testing of trading strategies

Asynchronous and Multithreaded Programming in MQL

Yuriy Asaulenko, 2019.07.27 21:25

You create a thread in the DLL and pass the data to it, disconnect the thread and forget about it - it will terminate by itself after finishing its task.
When you disconnect the thread in the DLL, the terminal thread is released. The whole process takes, I believe, less than a millisecond.
Judging by the fact that even without disconnecting the thread, the process of writing to the database is 4-5 ms. Well, 60 ticks/s is enough to not be sad about the asynchronous call from the terminal.


 
Roman:

No, you need to understand it, you've written the sequence yourself, so I thought you'd know it well.
At least what to read on the subject?

No need to understand it, modify it, etc. You create a DLL project in VS, DllMain() is created by itself. All Windows applications automatically support it.

Your task is to write export functions and besides them, any C++ code you need. Your DLL is ready and will work.

OOP is designed primarily to apply objects without having any idea about their inner workings, so that you can focus on solving exactly your task, rather than learning everything and anything. We drive a car, and we may have no idea about its electronics and engine construction. It's the same in the case of the DLL.

And the DllMain() function I cited earlier is taken from a real project of a rather complex DLL, which performs its tasks.

 
Yuriy Asaulenko:

No need to understand it, modify it, etc. You create a DLL project in VS, DllMain() is created by itself. All Windows applications automatically support it.

Your task is to write export functions and, besides them, any C++ code you need. Your DLL is ready and will work.

OOP is designed primarily to apply objects without having any idea of their inner workings. We drive a car and we may have no idea about its electronics and engine construction. In the case of the DLL, it's the same.

This is understandable, the functions themselves are not a problem, with all the conventions as in Articles 1 and 2 there is no problem with this.
But as I assume, to create a thread forthe called function,
in the DLL_THREAD_ATTACH case, we need to do some C++ fiddling
allocate memory, create a thread for the function,
and then clean it all up in DLL_THREAD_DETACH, so it's not as easy as it looks.

Why I say so, because I tried one asynchronous library, in which tasks are executed asynchronously,
I wanted to make a dll from this library, but for some reason it always crashes at the end of the program, i.e. deleting Expert Advisor from the chart.
For this reason it is necessary to fiddle with the entry and exit point.

 
Roman:

This is why you have to fiddle with the entry and exit point.

...i.e. removing the EA from the chart, my terminal crashes.

You don't have to. It's not the entry point that's to blame. You're doing something wrong.

Classes, threads, etc., etc. - all this is perfectly created and works fine in the DLL without any shamanism. But, by the time you exit, all YOUR processes in the DLL must be terminated and the objects destroyed. When debugging the DLL this happens). In C/C++ all control is the task of the programmer, not the program.

ZS I do it like this. I call a DLL function from an application, say

bool job =true;

void Close() 
{
	 job = false;
	 delete Obj1;
	 delete Obj2;
	......
}
By job=false all processes are terminated, by delete all objects for which memory was allocated are deleted, etc.
 
Yuriy Asaulenko:

But, by the time you leave, all YOUR processes in the DLL must be completed.

That's probably the problem, I didn't know that, I thought that the dll completes its own processes when it de-attaches.
I'll think about it how to terminate all processes before exit, thanks for the tip.
But justDLL_PROCESS_DETACH is responsible for it, and we need to forcefully kill all processes in this case.

 
Roman:

Butthis is exactly what DLL_PROCESS_DETACH is responsible for, and all processes must be forcibly killed in this case.

It is responsible for the DLL's deconnect with the application. DllMain() is responsible for maintaining standard communication protocol.DLL_PROCESS_DETACH is about other things.) Your processes are not interested in it, it is solely your business.

In MT there is a shutdown function. I think it is OnClose(). Here, from it, all processes and terminate by calling the appropriate function DLL.

 
Yuriy Asaulenko:

It is responsible for disconnecting the DLL from the application. It's not interested in your processes, it's entirely up to you.

OK, I'll try it out. Thank you for taking the time to explain the finer points, thank you.