Callback to MQ5 code from DLL - page 3

 
ggmoritz #:

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.

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

I am fine with your explanation, and I see where the polling is taking place.

So you want to use one EA to send data to the DLL. And you want one EA to receive commands from the DLL.

How is the receiving EA going to work without polling???

According to your definition of polling, now the DLL needs to be polling (except when you use a mutex between the sending EA and the receiving DLL (actually, that would be considered also polling, but the OS is doing it in this case) and the receiving EA is also polling...

Well, that's my understanding at least so far.

Sorry, but I have an aversion towards "autocorrection on steroids" aka AI LLMs.


 
Maybe you want to check this out:


I am not certain this still works...
Hello, my question - Pointers to the Functions. - How do you know Assembler?
Hello, my question - Pointers to the Functions. - How do you know Assembler?
  • 2022.01.01
  • www.mql5.com
A have 20-years experience of coding in assembler you called. It had 4kb of code you called "binary container. Please do not answer on this topic if you dont know assembler. In fact, i believe these are real pointers in the sense of a memory address
 
Dominik Egert #:
I am fine with your explanation, and I see where the polling is taking place.

So you want to use one EA to send data to the DLL. And you want one EA to receive commands from the DLL.

How is the receiving EA going to work without polling???

According to your definition of polling, now the DLL needs to be polling (except when you use a mutex between the sending EA and the receiving DLL (actually, that would be considered also polling, but the OS is doing it in this case) and the receiving EA is also polling...

Well, that's my understanding at least so far.

Sorry, but I have an aversion towards "autocorrection on steroids" aka AI LLMs.


I strongly doubt that the OS is doing polling when using synchronization primitives (condvars or mutexes) - but i'm not deep enough to be 100% certain, i might be wrong here.
The latency from blocking and waking the thread once a signal is ready seems to be 10-20 microseconds on my hardware. orders of magnitude faster than what possible using manual polling in OnTick or OnTimer.
If my plan will actually work out we'll see :), i feel like there could be something I missed

I'll come back later to the link you sent
 
ggmoritz #:
I strongly doubt that the OS is doing polling when using synchronization primitives (condvars or mutexes) - but i'm not deep enough to be 100% certain, i might be wrong here.
The latency from blocking and waking the thread once a signal is ready seems to be 10-20 microseconds on my hardware. orders of magnitude faster than what possible using manual polling in OnTick or OnTimer.
If my plan will actually work out we'll see :), i feel like there could be something I missed

I'll come back later to the link you sent
In the link I show how to get actually real memory addresses from functions as well as from variables. - And that rude guy seemed to be able to use them actually in assembler.

There is actually only one method known so far that is not considered polling, if polling is the proactive checking for a change: Hardware interrupts. They are implemented in hardware, directly inside the CPU. Everything else is proactive checked by some software code for a change.

The line between "polling" and "non polling" is usually drawn between user-space and kernel-space. - At least that's how I distinguish between polling and non polling. Though, I also put on top, is it blocking or not. And if it is a non blocking mechanism, I don't consider it being polling, but asynchronous synchronization. The exception to this are to my understanding when you use Kernel-driven mechanics like semaphores, mutexes or atomic operations. Because they are not in user space.

That's my approach, and way of looking at it.

Most modern hardware nowadays uses other methods than interrupts to make data available, like your network card, it uses DMA.


 
Dominik Egert #:
In the link I show how to get actually real memory addresses from functions as well as from variables. - And that rude guy seemed to be able to use them actually in assembler.

There is actually only one method known so far that is not considered polling, if polling is the proactive checking for a change: Hardware interrupts. They are implemented in hardware, directly inside the CPU. Everything else is proactive checked by some software code for a change.

The line between "polling" and "non polling" is usually drawn between user-space and kernel-space. - At least that's how I distinguish between polling and non polling. Though, I also put on top, is it blocking or not. And if it is a non blocking mechanism, I don't consider it being polling, but asynchronous synchronization. The exception to this are to my understanding when you use Kernel-driven mechanics like semaphores, mutexes or atomic operations. Because they are not in user space.

That's my approach, and way of looking at it.

Most modern hardware nowadays uses other methods than interrupts to make data available, like your network card, it uses DMA.


This forum is about MQL and MQL user space, so it's always polling. Very simple.
Reason: