Actually I would find a lot more useful to be able to start/stop or check if a service is running (easily) by code then adding/removing it which is the user responsibility (as everything similar on MT5 environment). Of course if we had also the possibility to add/remove a service by code, that would be good, but that's not really something critical at all.
The most important in my opinion would be to have some API to interact with services, from EA, indicators, or other services.
Yes, in fact process or better task/thread management would be really nice.
Also inter-"process" exchange beyond GTvars, which is quite limited.
One possible solution would be to use a file based approach, but that's all more or less a workaround, at least for the inter-process communication.
And using GTvars to manage the state of processes will only work, if they are coded by the same person, or have the same mechanics implemented. No general approach possible.
We can get all names from all running EAs, Scripts and Indicators, but not from services. They are more or less completely independent from the rest of MQL5.
But they can be used to monitor start and stop all other programs.
Regarding Sockets and Named-pipes, unfortunately MetaTrader can only act as a "client" and not a "server", so they are not suitable for MQL5 Services.
RAM-Disk based files requires external intervention to set up, so they are not suitable at all.
Memory mapped files can only be created via DLL calls, so it is also not suitable.
The result is that there is no suitable and reliable built-in way for MQL5 Services to communicate and "serve" other MQL5 programs.
If MT would serve as a server, named pipes would be possible.
On the other hand, shared memory would be even better. Some function like CreateSharedMem(string secure_access_token, T& arr[]) and OpenSharedMem(string secure_access_token).
Giving us a handle so we can use CopyBuffer () to access the memory.
I guess that would already be enough to do the job. - Although I can think of multiple better solutions...
If MT would serve as a server, named pipes would be possible.
On the other hand, shared memory would be even better. Some function like CreateSharedMem(string secure_access_token, T& arr[]) and OpenSharedMem(string secure_access_token).
Giving us a handle so we can use CopyBuffer () to access the memory.
I guess that would already be enough to do the job. - Although I can think of multiple better solutions...
The plan to implement Shared Memory has been abandoned.
Allow the use of cookies to log in to the MQL5.com website.
Please enable the necessary setting in your browser, otherwise you will not be able to log in.
You are signed in. Two-factor authentication has been disabled. Set it up again and scan a new QR code, or continue with two-factor authentication disabled.
Regarding Sockets and Named-pipes, unfortunately MetaTrader can only act as a "client" and not a "server", so they are not suitable for MQL5 Services.
RAM-Disk based files requires external intervention to set up, so they are not suitable at all.
Memory mapped files can only be created via DLL calls, so it is also not suitable.
The result is that there is no suitable and reliable built-in way for MQL5 Services to communicate and "serve" other MQL5 programs.
Actually I would find a lot more useful to be able to start/stop or check if a service is running (easily) by code then adding/removing it which is the user responsibility (as everything similar on MT5 environment). Of course if we had also the possibility to add/remove a service by code, that would be good, but that's not really something critical at all.
The most important in my opinion would be to have some API to interact with services, from EA, indicators, or other services.
Regarding Sockets and Named-pipes, unfortunately MetaTrader can only act as a "client" and not a "server", so they are not suitable for MQL5 Services.
RAM-Disk based files requires external intervention to set up, so they are not suitable at all.
Memory mapped files can only be created via DLL calls, so it is also not suitable.
The result is that there is no suitable and reliable built-in way for MQL5 Services to communicate and "serve" other MQL5 programs.
The plan to implement Shared Memory has been abandoned.