![MQL5 - Язык торговых стратегий для клиентского терминала MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
То есть инициализировать в DLL_PROCESS_ATTACH: будет достаточно для вызова из mql программы?
Из mql программы вызывать свои функции, расположенные в dll.
Из mql программы вызывать свои функции, расположенные в dll.
И в чем проблема описать их сигнатуры? Вы же winapi как-то дергаете через сигнатуры методов?
А, простите, зачем их описывать? И, простите, я ничего не дергал))
А, простите, зачем их описывать? И, простите, я ничего не дергал))
Уважаемые форумчане.
Андрей, то что асинхронность и многопоточность это разные вещи, думаю все это понимают.
Так как в инклуднике WinAPI описана функция CreateThread(), то было предположено что можно использовать потоки.
И описанных функций на подобие CreateTask() в инклуднике нет, то и предполагать возможное асинхронное написание кода, как то отпадает само собой.
По этому был сделан акцент на потоки. Но как выяснилось, что описанные функции это всего лишь прототипы WinAPI.
Повторюсь, была задача использовать чистый WinAPI, а описанный прототип CreateThread() ввёл в заблуждение. Ведь не где не сказано что это прототипы.
У всех задачи разные, вот и добрался до асинхронности, да и вообще считаю лучше всегда писать асинхронно или в потоках,
а выработанная привычка всегда писать асинхронно, позволит писать быстрые программы, и поднять ваш уровень как специалиста.
Это же основной принцип самих же разработчиков, скорость выполнения mql программ, это наше всё!
Очень жаль что в mql нет такой возможности,
по этому вношу предложение для администрации, разработать стандартные mql функции для асинхронного программирования,
раз с потоками есть проблемы и прежде всего безопасность.
Для асинхронного режима думаю нет препятствий в безопасности.
Примерная логика
Проработать реализацию EventLoop в mql
создать класс MqlTask
объявляем задачи как объект MqlTask obj;
создаём задачи task = obj.CreateTask(MyFunc());
запускаем на выполнение success = task -> Run();
приостанавливаем выполнение success = task -> SleepMs(ms);
ждём выполнения success = task -> Wait(ms);
ждём бесконечно success = task -> Wait(0);
удаляем задачу после выполнения delete task;
ну и всякие getStatus ы, для контроля
Андрей, то что асинхронность и многопоточность это разные вещи, думаю все это понимают.
Так как в инклуднике WinAPI описана функция CreateThread(), то было предположено что можно использовать потоки.
И описанных функций на подобие CreateTask() в инклуднике нет, то и предполагать возможное асинхронное написание кода, как то отпадает само собой.
По этому был сделан акцент на потоки. Но как выяснилось, что описанные функции это всего лишь прототипы WinAPI.
Повторюсь, была задача использовать чистый WinAPI, а описанный прототип CreateThread() ввёл в заблуждение. Ведь не где не сказано что это прототипы.
У всех задачи разные, вот и добрался до асинхронности, да и вообще считаю лучше всегда писать асинхронно или в потоках,
а выработанная привычка всегда писать асинхронно, позволит писать быстрые программы, и поднять ваш уровень как специалиста.
Это же основной принцип самих же разработчиков, скорость выполнения mql программ, это наше всё!
Очень жаль что в mql нет такой возможности, по этому вношу предложение для администрации, разработать стандартные mql функции
для асинхронного программирования, раз с потоками есть проблемы и прежде всего безопасность.
Для асинхронного режима думаю нет препятствий в безопасности.
Проработать реализацию loop циклов, и исполнять задачи в этих циклах.
Вы уж определитесь ассинхронно или многопоточно вы хотите выполнять методы. Я с сокетами, например, ассинхронно из mql работаю.
Для того чтобы определиться, нужно сперва понять, что возможно использовать в mql, а что под запретом.
В инклудниках был найден CreateThread(), по этому думал можно работать с потоками.
Но как выяснилось потоки запрещены, тогда выбор падает на асинхронность, но как использовать асинхронность из mql тоже не ясно.
Да, как раз проблема с сокетами. В справке говориться, что сокетов можно создать не более 128, что ограничивает получение информации к примеру по американским акциям.
И даже эти 128 сокетов не понятно как перевести в асинхронный режим, чтобы не было задержек в обработке приходящих данных.
По этому пришлось искать решение проблемы другим способом, но хотел решить её на чистом WinAPI без самописных dll.
А вот как работать асинхронно в mql это уже интересно, если есть рабочие примеры было бы не плохо обсудить их, если поделитесь информацией.
Но стандартных асинхронных методов в справке mql я что то не наблюдаю.
Для того чтобы определиться, нужно сперва понять, что возможно использовать в mql, а что под запретом.
В инклудниках был найден CreateThread(), по этому думал можно работать с потоками.
Но как выяснилось потоки запрещены, тогда выбор падает на асинхронность, но как использовать асинхронность из mql тоже не ясно.
Да, как раз проблема с сокетами. В справке говориться, что сокетов можно создать не более 128, что ограничивает получение информации к примеру по американским акциям.
И даже эти 128 сокетов не понятно как перевести в асинхронный режим, чтобы не было задержек в обработке приходящих данных.
По этому пришлось искать решение проблемы другим способом, но хотел решить её на чистом WinAPI без самописных dll.
А вот как работать асинхронно в mql это уже интересно, если есть рабочие примеры было бы не плохо обсудить их, если поделитесь информацией.
Но стандартных асинхронных методов в справке mql я что то не наблюдаю.
Читаю вот умных участников, и недоумеваю...
А зачем все эти навороты ?
Можно привести пример, когда бы в MQL так ужасно была бы необходима многопоточность ? По мне - так единственное применение - это тестирование стратегий, которое вполне нормально реализовано штатными средствами.
По идее, может иметь смысл запускать несколько WebRequest'ов, но, на мой взгляд, многопоточность при этом совершенно не требуется.
Какие задачи прям так требуют многопоточности ?