Callback to MQ5 code from DLL - page 2

New comment
 
ggmoritz #:

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

Actually No.

I noticed Fernando also had issues understanding what the actual approach is.

You need to look at the EA thread as a shared resource, your threads in the DLL are blocking, not the thread in the EA.

That's why you need to approach it from a semaphore standpoint.

Aside that, my suggestion would be to completely eliminate the need for a callback function on the EA side. Make it fully asynchronous.

One side prepares data, the other side gathers data when it requires these.

Do that for both sides and you have an interlocking system that works fully asynchronous. Just watch out for race conditions.
 
Dominik Egert #:
One side prepares data, the other side gathers data when it requires these.
That is literally polling
 
ggmoritz #:
That is literally polling
I guess this depends on your definition... But, okay.

Then why not go with a semaphore? - Actually, you are not giving enough information to make a better suggestion.

If you want some advice, you need to be clear about what you are trying to achieve.

I gave a few possible solutions, maybe you can put them to use in a creative way, such that the processes/threads are not blocking.

The main issue is the thread in the EA. That's the asynchronous process you have no real control over, if you want the terminal to have full control of the thread.

Else, maybe it's possible to get the mutex of the EA thread that the terminal is using, if it is using such. - Sadly it is not documented how the terminal manages the threads.

But if you want a fully asynchronous concept, you have no other option than the ones i have described. At least I cannot think of any other...

You?
 
ggmoritz #:
That is literally polling
Just to be clear, polling involves the repeated gathering of data until the expected data is available. This I usually done in a loop, blocking further processing.

Contrary to that, I suggested to just read the currently present dataset and continue processing. If it hasn't changed, and no processing is required, you simply return from the OnTick back to the terminal, and wait for the next Tick to come. - Here you can now update data that's required for the DLL. The DLL can now read updated data, asynchronous from the EA.

In the meantime, the DLL might have prepared new data and makes it available to be read by the EA.

Now the EA receives a new tick, reads the new data and continues processing.

That is not polling.
 
Dominik Egert #:
Just to be clear, polling involves the repeated gathering of data until the expected data is available. This I usually done in a loop, blocking further processing.

Contrary to that, I suggested to just read the currently present dataset and continue processing. If it hasn't changed, and no processing is required, you simply return from the OnTick back to the terminal, and wait for the next Tick to come. - Here you can now update data that's required for the DLL. The DLL can now read updated data, asynchronous from the EA.

In the meantime, the DLL might have prepared new data and makes it available to be read by the EA.

Now the EA receives a new tick, reads the new data and continues processing.

That is not polling.

Come on Dominik, of course it's polling.

Anyway, with MT5/MQL5, you can imagine a lot of variations on polling, with a loop, events or whatever, in the end it will ALWAYS be polling because you can't call an MQL function (or trigger an event, which is the same technically) from outside.

Though if the algo allows it, you can simulate a callback with a timer (maximum delay is around 16 milliseconds).

 
Dominik Egert #:
That is not polling.

Just because you aren't blocking the thread, doesn't mean it's not polling.
Polling is just sampling the data with a time delay until something interesting happens, that's what happens here as well.

Dominik Egert #:
If you want some advice, you need to be clear about what you are trying to achieve.

What else do you need to know? I already said the following in this thread (granted, a bit spread around multiple messages), which is all I deem interesting
- The DLL needs to be informed about every new tick price
- The DLL uses the given data as well as outside factors to decide when to open trades
- The trading signals can be initiated by the call to the DLL with tick price data (no polling or callbacks required here) BUT also by external factors independent of the terminal (would require callbacks or polling)
- I want to keep the latency to a minimum, which is why i would like to avoid polling

Dominik Egert #:
But if you want a fully asynchronous concept, you have no other option than the ones i have described. At least I cannot think of any other...

You?

At the end of my last post I mentioned an idea about using 2 expert advisors at once (or alternatively single EA with an indicator)
Not sure how well i phrased that idea.
Comes down to the following:
- problem would not exist if we had two threads on the MQ5 side
- second EA = second thread
- the first EA sends all price tick updates, the second EA blocks (semaphore, mutex, channel, whatever) until it receives a trade signal from the DLL - then immediately executes it
- profit

 
Alain Verleyen #:

Come on Dominik, of course it's polling.

Anyway, with MT5/MQL5, you can imagine a lot of variations on polling, with a loop, events or whatever, in the end it will ALWAYS be polling because you can't call an MQL function (or trigger an event, which is the same technically) from outside.

Though if the algo allows it, you can simulate a callback with a timer (maximum delay is around 16 milliseconds).

I don't want to get into an argument about asynchronous process IO.

It is most probably a fine line of definition. Under Linux it's done by LibAIO and on Windows it's done via IOCP.

While in fact all are polling, except for actual CPU interrupts, there is a difference on who does the "polling" and how...

So, fine, let's agree to whatever method of nonblocking asynchronous IO is possible with an EA is always involving polling.
 
ggmoritz #:

Just because you aren't blocking the thread, doesn't mean it's not polling.
Polling is just sampling the data with a time delay until something interesting happens, that's what happens here as well.

What else do you need to know? I already said the following in this thread (granted, a bit spread around multiple messages), which is all I deem interesting
- The DLL needs to be informed about every new tick price
- The DLL uses the given data as well as outside factors to decide when to open trades
- The trading signals can be initiated by the call to the DLL with tick price data (no polling or callbacks required here) BUT also by external factors independent of the terminal (would require callbacks or polling)
- I want to keep the latency to a minimum, which is why i would like to avoid polling

At the end of my last post I mentioned an idea about using 2 expert advisors at once (or alternatively single EA with an indicator)
Not sure how well i phrased that idea.
Comes down to the following:
- problem would not exist if we had two threads on the MQ5 side
- second EA = second thread
- the first EA sends all price tick updates, the second EA blocks (semaphore, mutex, channel, whatever) until it receives a trade signal from the DLL - then immediately executes it
- profit

Yes, I did read that, but all it does is split the task, and still poll your DLL...

My initial idea of using semaphore still stands as non-polling inside the user-space.

The second idea I have proposed, the asynchronous IO between DLL and EA, time interlacing data processing. It is at least non-blocking. Even if it might be understood as "polling", which I don't see that way, but whatever floats your boat.

In the end, all I was aiming at, is provide some ideas and inspiration.

If you want a ready made solution, custom fit to your task, I guess, it's actually up to you.

All this debating has at least driven my imagination to find a solution so far down, I am not actually able to offer more support at this point.


 
Let me try to express an asynchronous process IO with a dialog:

Voice from above (Terminal):
Let's start this EA, and load it's required DLL. I will call the OnInit.

EA: Oh, I am being activated, that's nice. Hey, DLL, please initialize.

DLL: Oh, I am being initialized, good. That went successfully EA, I am ready.

EA: Hey Terminal, I am ready!

Terminal: good, so you wait now, I'll inform you of updates.

EA: Oh, an Update (OnTick). Hey, let's check if DLL has new data for me. - Nope. OK. Hey, DLL, I have new data for you. (Calling function of DLL, handing data). Hey Terminal, I am done.

DLL, oh, a notification (function got called) for new data, let's process this and make it available as soon as I am done.

Terminal: hey, EA, new Update.

EA:Oh, update. Let's see if DLL is ready or not.
Nope, but I'll notify DLL of new data. Terminal, I am done.

DLL: Oh, new data, let's process... (First thread in DLL: oh, I am done, let's make it available to the EA.

Terminal: EA, new Update.

EA: Oh, yes, let's check if DLL has data for me. It has, great, let's process that data... And notify DLL of new data.


And so on, I guess you get the point.

But in this process, where would you place the "polling"? - Just so I understand what the difference in perspective here is.

 
Dominik Egert #:
EA: Oh, an Update (OnTick). Hey, let's check if DLL has new data for me. - Nope. OK.

Right here is where the polling takes place.
Reading a variable in an interval and acting upon it is polling. Only if the DLL side could "directly" inform the EA without any delays, I wouldn't consider it polling.

Dominik Egert #:
Yes, I did read that, but all it does is split the task, and still poll your DLL...

Now I'll return the question to you: where does the polling take place here?
From what I can see the second EAs thread will get blocked but without polling (would be waked up by some form of synchronization primitive)

I think you might be mixing up polling and blocking. ChatGPT gives a surprisingly good comparision: https://chat.openai.com/share/66952c20-2f72-45cd-ac7c-6cdd71b71b79

123
New comment