Указатель указателя или Наследовать

здесь
я вот тоже подумала (про своих баранов) - если у меня 2 thread'a (gui и secondary) и в secondary задан классом (как здесь), в котором работает функция, которая отдаёт массив в класс, ход обработки массива методом этого (куда отдаёт) класса - отразить в gui хочется... !?!
вот передаю указатель на Form из класса gui в класс secondary worker thread... (как по примеру #222)
а дальше?..
указатель на указатель параметром в др класс передавать? (что-то не проходит)?
передаю банально:
ну или **
как не пытаюсь передать указатель на указатель или тот же указатель на gui в др класс - выдаёт, что инициализация gui возможна только в первичном потоке...
- а ведь только передать хочу указатель на то, что уже было проинициализировано в первичном потоке... т.е. на сам gui
ИЛИ ???
может, мне лучше наследовать 2-й класс (loadV) от класса worker и в нём поле "принятый из gui указатель" сделать protected?
(чтобы не заморачиваться передачей указателя на gui и уж тем более транслированием в gui поток из класса, куда передаём массив после его сбора в классе worker - который во вторично потоке от gui)...

0

Сообщение от JeyCi например макросом коллбэка, как в примере GoshaM...

В общем случае нет. В приведённом примере у GoshaM это именно прямые вызовы, пусть и разложенные в разные потоки. А события - это записи в очередях событий, которые в Qt записываются при обработке сигналов и считываются при выполнении метода exec() соответствующего объекта (в соответствующем ему потоке).

Добавлено через 7 минут
Опять же, в случае Qt мьютексы автоматически ставятся на разграничение записи и чтения из очереди (иначе возможна "гонка" между потоками, с недозаписыванием/недосчитыванием элемента).

0

Сообщение от TRam_ В приведённом примере у GoshaM это именно прямые вызовы

здесь? -это как раз в U++ макрос для коллбэка...
вы, наверно, имели ввиду этот его вариант

Сообщение от TRam_ Опять же, в случае Qt мьютексы автоматически ставятся на разграничение записи и чтения из очереди

ну там как бы м компилятор вроде другой -

В библиотеке Qt Метаобъектный компилятор

- делает сам часть работы для реализации паттерна Наблюдатель, реализованного для сигнально-слотовой системы...

Сообщение от TRam_ (иначе возможна "гонка" между потоками, с недозаписыванием/недосчитыванием элемента).

вот и говорю, синхронизация нужна, видимо... в U++ ... тоже думаю, что мьютексами надо обеспечить её (что-то зону видимости volatile Atomic Stopped не могу настроить для передачи из gui в метод класса, объект которого запускается во вторичном потоке -- намутила уже тут -- в класс залезла со своим gui -- а вылезти не могу пока )...
а то как-то ни передача ссылки, ни захват контекста - не дают адекватной обратной связи (от gui к потоку)...
надо пробовать, как здесь , наверно??...
потому что, если послать ещё можно попробовать Event'ом U++... но отловить во вторичном потоке смену флага isInterruptionRequested (да даже не в потоковой функции, а в классе, чей объект работает в этой потоковой функции) - как-то пока ...
вот и интересуюсь - а как там по стандарту - синхронизировать? или лямбдой можно справиться? (захватывая контекст)...
всё равно путь от gui до member-method'а класса через вторичный поток -- ой какой-то далёкий
вот и изложила свои сомнения...

Добавлено через 8 минут
наверно, действительно, пока объект крутит в себе свой метод - залезть туда с переменной из другого потока не так-то легко - тут уж очередь event'ов (в отличие от gui) отсутствует...

Добавлено через 2 минуты
хотя event в U++ - это обычный коллбэк...

0

Сообщение от JeyCi синхронизировать?

я, наверно, погорячилась...
хотя и это тоже надо в жизни...
а ведь с сокетами всё должно быть проще ... закрываем и объект сам вернёт error на вызывающую сторону... которую просто обработать и return из потоковой функции, даже Thread::Shutdown не надо делать экстренно по кнопке с bStopped... и уж тем более передавать этот bStopped...
p.s.
хотя, конечно, если сокет открыт во вторичном потоке - то, может, и надо туда постучать из gui под мьютексом??.. но что-то мне кажется, что сокет из любого потока виден без мьютексов... просто убить/закрыть его... имхо... чего уж тут что-то локировать для передачи message'ей или дёргать volatile Atomic bStopped...
p.p.s.
и с коллбэками - как возможностью независимого исполнения кода - действительно, становится не страшно, когда смотришь на лямбду, как положено, - т.е. как на анонимную функцию...
Vector<Event<>> cb; - тоже удобно в U++

0

Сообщение от GoshaM Worker ничего не знает о GUI:

однако...

According to OOP paradigm, each class must have everything possible within it. It must be it`s own model, view and controller (MVC) - in one place.

- тоже имеет смысл в более узком контексте!...

Добавлено через 2 минуты
и с удобным Фреймворком - и того не надо... just use objects!
это я к тому, что Декомпозиция нужна - только если, действительно, упрощает either чтение кода or его сопровождение...
=============================
Добавлено через 1 час 34 минуты

Сообщение от JeyCi ?? а в U++ если кнопкой запускаем Event в btnStopped смены флага isInterruptionRequested - как правильно по уму отловить в потоке?

знакомо:

Сообщение от JeyCi deadlock

Боремся с deadlock-ами
Ctrl::Call
- чувствовала я, что &ConditionVariable надо как-то впаять... а он то уже есть...

Добавлено через 2 часа 43 минуты
ИТОГО:

Сообщение от JeyCi -- в класс залезла со своим gui -- а вылезти не могу пока )...

а просто не надо с кнопки в вызываемом из вторичного потока member-method'e делать ShutdownThreads(); ...
а там надо обработать нажатие кнопки stop, вернуть false в вызывающий поток, завершить в нём функцию... и, наверно, отправить в detach ...
по ходу отловить его при новом старте, вероятно, через тот же ConditionVariable... т.к. в любом случае новое создание/уничтожение потока - дорого стОит...
p.s.
только , вероятно, где-то потеряла какой-то pointer или reference... т.к. error на Destructor'e главного окна предупреждает о том, что "возникшая проблема привела к прекращению работы программы. закройте эту программу"
опять чьё-то "время жизни", наверно

0

Сообщение от JeyCi и, наверно, отправить в detach

Не надо.

1

Сообщение от DrOffset Не надо.

но вы вроде сами советовали - усыпить, потом разбудить (когда надо опять его использованть)... пока не нашла как?..
насчёт detach - верю - экстремально... (но менее экстремально, чем убить сокет ... просто http.Abort() достаточно)

0

Сообщение от JeyCi но вы вроде сами советовали

Вы, пожалуйста, не мешайте в кучу все, что я говорил.
detach - не надо делать.

Добавлено через 46 секунд

Сообщение от JeyCi пока не нашла как?..

на condition_variable, например, он может уснуть.

0

Сообщение от DrOffset не мешайте в кучу все, что я говорил. detach - не надо делать.

значит не вы, а один из линков по вашему совету

давайте не будем придираться к словам...
ссылку на совет "не удалять поток, а усыплять его и будить при необходимости" не оставлю - искать надо...
НО чтобы будить - надо ведь, наверно, чтобы условно listener, спящий, - слушал сигнал, который даст разрешение проснуться... т.е. каждые, например sleep(250) - false awakening у него, чтобы были... типа того, полагаю... ну да ладно - дочитаю у Вильямса - когда дойду до практики...
p.s.
но о вашем совете - ещё, конечно же, подумаю... спасибо

0

Сообщение от JeyCi значит не вы, а один из линков по вашему совету

Ну так вы прочитайте к чему там он используется по-внимательнее.

Добавлено через 2 минуты

Сообщение от JeyCi НО чтобы будить - надо ведь, наверно, чтобы условно listener, спящий, - слушал сигнал, который даст разрешение проснуться

condition variable как раз для этого и нужен.

Добавлено через 5 минут

Сообщение от JeyCi давайте не будем придираться к словам...

Это не придирки к словам, а попытка пресечь неверную интерпретацию моих слов или приписывание мне того, чего я не говорил.
Это худшее, что может произойти.
В общем и целом посыл такой: я не понимаю при чем тут усыпление потока к моим словам про detach. В общем случае это ортогональные вещи. Поэтому возражения "но вы сами советовали..." мне не понятны.

Пример из блога - иллюстрация, которая показывает эмуляцию join. Это не значит, что при любом использовании condition variable обязательно нужен detach. Это ниоткуда не следует и ни автором блога, ни мной в виду не имелось.

0

Сообщение от DrOffset Это не значит, что при любом использовании condition variable обязательно нужен detach. Это ниоткуда не следует и ни автором блога, ни мной в виду не имелось.

мной тем более!

Сообщение от DrOffset пресечь неверную интерпретацию моих слов или приписывание мне того, чего я не говорил.

и мне того же...
===

Сообщение от DrOffset при чем тут усыпление потока к моим словам про detach.

не при чём...
1) просто detach, возможно тоже можно вернуть (по коду, пример которого приложила) - ещё не тестила этот подход...
2) про detach обсуждали - его бессмысленность сомнительна для меня пока - иногда можно себе и позволить (если разрабатываемый app ещё не претендует на супер-сложность)...
3) про усыпление - отдельная история - но если detach можно отловить cv-ом, то почему бы и не дать ему погулять или там же поспать (в отвязке)?... погулять, конечно, плохо - туда можно вклинить чужой (даже хакерский) код, наверно...
[хотя реализация так себе, имхо, 1 поток можно и создать и join - и норм. недолго, уже если много - то стоит подумать о времени =>thread-pool'е]
p.s.
но всё-таки моменты неблокирующей реализации потоков - основной смысл интереса к этой теме - чтобы много асинхронного кода не давало по факту синхронного исполнения -
хочу добиться и, действительной асинхронности и скорости и недорогого возврата результатов в основной рабочий поток - для дальнейшей обработки... и идеи пока есть!

Сообщение от DrOffset Не надо.

но ведь голословно.... без аргументов....

Добавлено через 4 минуты
аргумент был лишь в прошлой ветке от oleg-m1973 - о limit in Windows ~500...

0

Сообщение от JeyCi но ведь голословно.... без аргументов....

Имею право. Посмотрите сколько уже лет я на форуме отвечаю.
Все уже отвечено по нескольку десятков раз. Поищите.

Вот
Thread на стеке
или вот Создание потока для вызова метода класса

Добавлено через 8 минут

Сообщение от JeyCi но если detach можно отловить cv-ом

Не ясно зачем это делать, если join делает тоже самое.

Сообщение от JeyCi если разрабатываемый app ещё не претендует на супер-сложность)

Вот именно потому, что у вас не "супер-сложный app", detach вам и не нужен.

0

... коль ветка начинает скатываться к обсуждению субъективных прав... напомню лишь, что суть проблемы была в организации communication в рамках с учётом нескольких потоков и силами U++... и линки по ветке - были ответами на возможности both по-быстрому & по-правильному по науке...
разбивка на классы добавляет сложностей в этом взаимодействии M и V... но и определяет пути для рефакторинга... остальное - дело вкуса... и сложности потребностей...

0

Сообщение от JeyCi по-правильному по науке...

Вот именно, что использование detach обычно выдает поверхностный подход к управлению контекстом потока. По крайней мере в примерах людей в этом разделе форума. Если я вам говорю, что этого делать не нужно, то по крайней мере это повод поискать материал.

0

Дипломатия - превыше всего

Сообщение от volovzi если программировать правильно, то получатся паттерны, а если программировать паттернами, то не факт, что получится правильно. Тебе сейчас надо не паттерны изучать, а алгоритмы.

Добавлено через 52 секунды

Сообщение от DrOffset подход к управлению контекстом потока

вот за это - спасибо... я всё контексты не научусь примерять... помозгую ещё... тут у меня просто ещё и классы наворачиваются... не говорила ведь, что всё легко... просто всё пошагово поэтапно... а гонять results и btnStopped всё равно надо будет в 2х направлениях - одно туда, другое сюда...

0

JeyCi, где ж тут паттерны? Выше даны ссылки на объяснение в процессе дискуссии чем чревато использование detach в неподготовленном окружении. Все показано, рассказано.

И что такого произошло недипломатичного? Я мог бы у вас попросить того же, потому что выше я просто озвучил свою позицию. За столько лет на форуме не всегда нужно повторять что-то еще раз. Это занимает много времени, а кто мне его вернет? Поэтому если я что-то и заявляю изначально "бездоказательно", то только лишь в расчете на вопрос "почему". Обратите внимание, что как только вы его задали, я выдал вам ссылки.

Не нужно эмоционально реагировать. В моих постах нет эмоций, только расчёт. Если вы прочитаете их спокойным тоном, без приписывания мне агрессии - это станет понятно.

0

Сообщение от DrOffset И что такого произошло недипломатичного?

обсуждение ваших прав... и ваш субъективизм о кажущихся вам эмоциях...

Сообщение от DrOffset Это занимает много времени, а кто мне его вернет?

Дипломатия - это разговор по теме, а не попытки спорами, правами и безапеляционностью вызвать меня на доказывание относительности моих реакций относительно моих задач... спасибо за ваш ответ вы получили от меня ещё там... ваш интерес к моему субъективизму за рамками темы - уж точно не правомерен даже в рамках ваших прав... offtop всё-таки...

Сообщение от DrOffset В моих постах нет эмоций, только расчёт.

если есть, что добавить по взаимодействию M и V без сигналов-слотов (и между потоками и между классами) -- тоже с интересом приму к сведению, как и все ваши советы... но подробностей всего тз - снова не предоставлю... offtop всё-таки...
в принципе варианты, как и ваш view уже вроде все озвучены...
и ваш совет из прошлой ветки:

уметь выделять главное

0

Сообщение от JeyCi ваш интерес к моему субъективизму за рамками темы - уж точно не правомерен даже в рамках ваших прав...

Мне не интересно, чтобы в теме появился конфликт. Поэтому я объясняю все свои поступки и слова. Больше никаких целей не преследовали посты выше.

0

Сообщение от DrOffset подход к управлению контекстом потока.

если, например, я захватываю в коллбэк ссылку на window (где кнопки и их методы) и ссылку на worker'a (где bool Stopped и запуск рабочего потока) -- то вот тут как раз с кнопки изменить boolStopped и не могу, если worker стартует с указателем на windows => туду всё выбросить может, а window's кнопка stop не может изменить состояние флага bStopped (потому что этот флаг- это поле worker'a)...
значит => чтобы иметь и обратную связь - мне надо также захватывать в окно и ссылку на worker'a... как и в worker'a я захватила ссылку на windows...
(как GoshaM показывал)
- ну в принципе работа над ошибками понятна по этой части...
НО помимо захвата в коллбэк... надо потом ещё захватить в новый thread, открываемый этим коллбэком, кнопку btnStopped... пока понимаю так

Добавлено через 3 минуты
т.е. 1-й захват (в worker_Class) с коллбэка, продолжить 2-ым захватом (в start_work методе того worker_class'a строкой кода thr.Run([m_pw->btnStopped]{}))... чтобы потом нормально принимать btnStopped сигналы... имхо

0

вышла из deadlock'a , закрыла поток... на том, что было... альтернативные варианты архитектуры ещё покручу

0

Сообщение от DrOffset detach - не надо делать. использование detach обычно выдает поверхностный подход к управлению контекстом потока.

вот такой ответ п.8 меня достаточно убеждает:

On the other hand, if we do not call join() after creating a thread in the above case, the main function will not wait for the spawned thread to complete before it tears down the application. If the application tears down before the spawned thread finishes, it will terminate the spawned thread as well, even if it has not finished executing. This can leave data in a very inconsistent state and should be avoided at all cost.

0