Callback to MQ5 code from DLL

New comment
 

A DLL is a major part of my expert advisor.
This DLL should be able to send signals to my MT5 terminal. This would either require polling, or a callback.
Such callback could for example be utilized to make a trade copier.

But it does not seem possible to pass functions as parameters in MQ5, neither was I able to get the address of a MQ5 function.
Has anyone succeeded at this or something similar before?

 
ggmoritz: A DLL is a major part of my expert advisor. This DLL should be able to send signals to my MT5 terminal. This would either require polling, or a callback. Such callback could for example be utilized to make a trade copier. But it does not seem possible to pass functions as parameters in MQ5, neither was I able to get the address of a MQ5 function. Has anyone succeeded at this or something similar before?

DLL functionality in MQL is limited in some aspects. It is somewhat "sandboxed" so callbacks are not possible. Instead, consider polling from the MQL program side.

 
Fernando Carreiro #:

DLL functionality in MQL is limited in some aspects. It is somewhat "sandboxed" so callbacks are not possible. Instead, consider polling from the MQL program side.

That's kind of a shame, as it unneccessarily increases the latency :/
 
ggmoritz #:
That's kind of a shame, as it unneccessarily increases the latency :/
since you are using DLLs anyways, and you are most probably using multi threads in the DLL, you are actually facing a thread/process sync task.

If that's the case, then you should use a semaphore to make the DLL sync with the EX5 executable. - As a sidenote, the EX5 should not be an indicator, because an indicator has not its own thread.

But this way you don't need a polling solution, but hava a signaling system.
 
Dominik Egert #:
since you are using DLLs anyways, and you are most probably using multi threads in the DLL, you are actually facing a thread/process sync task.

If that's the case, then you should use a semaphore to make the DLL sync with the EX5 executable. - As a sidenote, the EX5 should not be an indicator, because an indicator has not its own thread.

But this way you don't need a polling solution, but hava a signaling system.

It is still a "polling" situation, even if it is using signalling. You still need to read the signal at a regular interval to detect the change, so it is technically still "polling".

 
Fernando Carreiro #:

It is still a "polling" situation, even if it is using signalling. You still need to read the signal at a regular interval to detect the change, so it is technically still "polling".

Actually not, if I am not mistaking. Semaphores block the thread and when the semaphore gets activated the OS actually activates that waiting thread and assigns a CPU slice to it.

These are windows OS native implemented, they work forward, without polling.

 
Dominik Egert #: Actually not, if I am not mistaking. Semaphores block the thread and when the semaphore gets activated the OS actually activates that waiting thread and assigns a CPU slice to it. These are windows OS native implemented, they work forward, without polling. https://learn.microsoft.com/en-us/windows/win32/sync/semaphore-objects

But that then defeats the purpose of multi-thread approach. Causing the EA's thread to block while waiting for the DLL to do it's job is already the default of a normal DLL call.

The idea of a callback, is to allow a separate thread to continue doing work and then calling the the main thread when it has completed.

In the absence of not being able to implement a callback, the option of polling serves to interrogate the state of the separate running thread, without blocking either thread.

 
Fernando Carreiro #:

But that then defeats the purpose of multi-thread approach. Causing the EA's thread to block while waiting for the DLL to do it's job is already the default of a normal DLL call.

The idea of a callback, is to allow a separate thread to continue doing work and then calling the the main thread when it has completed.

In the absence of not being able to implement a callback, the option of polling serves to interrogate the state of the separate running thread, without blocking either thread.

I guess, this depends very much on how you implement the whole system. - There is a reason for semaphores to be used as process and thread synchronization tool.

Surely, you are to some extend right, you dont want your main thread to be blocked, but you surely would implement workers, which will have to wait. - Usually this is called walling or gating, standard practice in iE OpenCL to synchronize the calculation threads.

There are for sure also techniques to implement non-blocking tread synchronizations, but not sure how you would do that for MQL, as this is only one thread. - so probably you would need to take account for such.

EDIT:

If it were a normal function call to the DLL, then there is no need for a callback in the first place.

 
Dominik Egert #:

I guess, this depends very much on how you implement the whole system. - There is a reason for semaphores to be used as process and thread synchronization tool.

Surely, you are to some extend right, you dont want your main thread to be blocked, but you surely would implement workers, which will have to wait. - Usually this is called walling or gating, standard practice in iE OpenCL to synchronize the calculation threads.

There are for sure also techniques to implement non-blocking tread synchronizations, but not sure how you would do that for MQL, as this is only one thread. - so probably you would need to take account for such.

EDIT:

If it were a normal function call to the DLL, then there is no need for a callback in the first place.

Yes, I understand and would agree if the MQL program was multithreaded, but its not.

The MQL program is single threaded, so trying to halt/block it as a means of "synchronising" does not seem useful.

Maybe I am just misunderstanding what you mean.

 
Fernando Carreiro #:

Yes, I understand and would agree if the MQL program was multithreaded, but its not.

The MQL program is single threaded, so trying to halt/block it as a means of "synchronising" does not seem useful.

Maybe I am just misunderstanding what you mean.

Well, a semaphore, contrary to a mutex, is used to get access to a limited resource.

So from the DLL perspective, independent of the amount of threads in the DLL, the MQL Thread is a shared resource. This resource is not necessarily blocked, but the DLL threads are. Depending on what the MQL thread is doing.

So if the MQL thread is currently waiting for OnTick, the thread could be sitting on the semaphore waiting for it to be signaled by a DLL thread. Then it could call the function from the DLL to fetch the data. (Like a callback)

I am not sure if that works this simple, maybe a second thread and a mutex is also required. Depending on how MT has it's thread synchronization implemented.

My idea was to look from the DLL towards the MQL thread. And treat it as a resource.
 
Dominik Egert #:
Actually not, if I am not mistaking. Semaphores block the thread and when the semaphore gets activated the OS actually activates that waiting thread and assigns a CPU slice to it.

These are windows OS native implemented, they work forward, without polling.

https://learn.microsoft.com/en-us/windows/win32/sync/semaphore-objects

If I understood you correctly, you suggest simply waiting for a signal (blocking the EA thread) in the OnTick function.
This sounds like it could work, but then I could no longer relay the tick data to my DLL.
Signals can also be triggered by external factors so it's not possible to know when to stop blocking in order to get and relay the new tick data.

I am however thinking about making and loading an indicator or second EA that uses the DLL, so I essentially get two threads
(1 for feeding the tick data into the DLL and 1 for executing the trades coming from the DLL).
hacky but promising solution

123
New comment
Reason: