В нашем случае мы реализовывали класс, описывающий hardware устройство со своими приколами. Так как железка была сугубо самодельная - работа с ней вынуждена стала многопоточной (на что повлиять мы не могли, поскольку протокол и железка делается вообще не нами). И по факту эти методы класса являлись обработчиками разнородной информации.
Схема примерно такая:
Получить данные от железки в буфер
Прочитаать заголовок
Определить тип оьработки
Направить буффер в конкретный обработчик в отдельном потоке
Проверить очередь команд для железки
Схема же обработчика следующая:
Принять буффер
Обработать данные
Сгенерировать ответ
Добавить ответ в очередь
Более того (почему не подходит async), обработка иногда занимает несколько секунд / минут и/или является накопительным алгоритмом от входных данных, что вынуждает делать метод практически полностью автономным в своём while (true) цикле.
Я понял почему такая ситуация: ранее в коде я хранил не сам поток, а ссылку на него и хотел сразу же при его завершении отчищать память по указателю. В связи с тем, что я ушёл от такого решения ... действительно более не требуется. Внесу правки, спасибо!
Дык история в том, чтобы в основном потоке программы дать команду на остановку и не ждать его завершения и идти дальше. А вот важен момент отслеживания реальной остановки треда и его очистки после. В любом случае коллеги уже дали несколько решений как задвинуть этот код на пыльную полку и сделать сильно лучше)
честно говоря не до конца понимаю при чём тут упоминание thread pool ... да, у нашей обёртки есть возможность помещаться в динамические STL контейнеры, но это не было самоцелью задумки. К тому же выше говорил, что действительно не сеньор и, вероятно, занимаюсь велосипедами)
уже после написания статьи и повторного курения стандарта мне пришло в голову, что даже имеющийся код можно было значительно упростить при помощи std::function. Я и не настаивал на том, что решение идеально)
Спасибо за развёрнутый анализ нашего кода и предложения, действительно выглядит красиво и лаконично.
В действительности мы тыкались и с async и с пресловутым thread в наши задачи и ... всё как-то не нравилось. Возможно действительно мы плохо изучили стандарт, чтобы удобно оперировать уже имеющимся функционалом.
Однако получившийся кусок кода настолько удачно встал у меня во все места в имеющимся проекте, что возникло ощущение надобности про это написать :) В любом случае задачка была интересная и опыта прибавила
Спасибо большое! Намудрил при вставке кода из проекта в статью, сейчас поправлю. На счёт delete не нуждается в проверке на nullptr ... честно говоря не знал. Век живи, век учись :)
В нашем случае мы реализовывали класс, описывающий hardware устройство со своими приколами. Так как железка была сугубо самодельная - работа с ней вынуждена стала многопоточной (на что повлиять мы не могли, поскольку протокол и железка делается вообще не нами). И по факту эти методы класса являлись обработчиками разнородной информации.
Схема примерно такая:
Получить данные от железки в буфер
Прочитаать заголовок
Определить тип оьработки
Направить буффер в конкретный обработчик в отдельном потоке
Проверить очередь команд для железки
Схема же обработчика следующая:
Принять буффер
Обработать данные
Сгенерировать ответ
Добавить ответ в очередь
Более того (почему не подходит async), обработка иногда занимает несколько секунд / минут и/или является накопительным алгоритмом от входных данных, что вынуждает делать метод практически полностью автономным в своём while (true) цикле.
Я понял почему такая ситуация: ранее в коде я хранил не сам поток, а ссылку на него и хотел сразу же при его завершении отчищать память по указателю. В связи с тем, что я ушёл от такого решения ... действительно более не требуется. Внесу правки, спасибо!
Дык история в том, чтобы в основном потоке программы дать команду на остановку и не ждать его завершения и идти дальше. А вот важен момент отслеживания реальной остановки треда и его очистки после.
В любом случае коллеги уже дали несколько решений как задвинуть этот код на пыльную полку и сделать сильно лучше)
Да, об этом и сказано было в послесловии и ... нам самим это совершенно не нравится)
честно говоря не до конца понимаю при чём тут упоминание thread pool ... да, у нашей обёртки есть возможность помещаться в динамические STL контейнеры, но это не было самоцелью задумки. К тому же выше говорил, что действительно не сеньор и, вероятно, занимаюсь велосипедами)
уже после написания статьи и повторного курения стандарта мне пришло в голову, что даже имеющийся код можно было значительно упростить при помощи std::function. Я и не настаивал на том, что решение идеально)
Спасибо за развёрнутый анализ нашего кода и предложения, действительно выглядит красиво и лаконично.
В действительности мы тыкались и с async и с пресловутым thread в наши задачи и ... всё как-то не нравилось. Возможно действительно мы плохо изучили стандарт, чтобы удобно оперировать уже имеющимся функционалом.
Однако получившийся кусок кода настолько удачно встал у меня во все места в имеющимся проекте, что возникло ощущение надобности про это написать :) В любом случае задачка была интересная и опыта прибавила
Спасибо большое! Намудрил при вставке кода из проекта в статью, сейчас поправлю. На счёт delete не нуждается в проверке на nullptr ... честно говоря не знал. Век живи, век учись :)