Возращаемое значение из Thread

@simplepilot · Регистрация: 22.07.2007

Студворк — интернет-сервис помощи студентам

Программа работающая как backgraund process устроена так, что получая запрос пользователя в виде XML сообщения она создаёт на его основе объект, а потом запускает этот объект выполняться как отдельный процесс. То есть программа занята тем только что получает сообщение и далее обрабатывает его специальный объект, работаюший как отдельный процесс (thread). Но есть одно но, программа должна отослать обратно клиенту ответ. И этот объект работающий как thread должен его как то программе обратно отдать. А вот можно ли так что бы какой то дочерний процесс вернул создавшему его процессу какое то значение.
При этом интересует две ситуации
1. Программа создаёт одновременно только один объект(дочерний процесс) и терпеливо ждёт когда он 'отстреляется' и отдаст ей результат.
2. Одновременно существует много объектов(дочерних процессов) и каждый из них как нибудь дёргает вызывающую программу. Типа - я отсрелялся, вот тебе строка результата, можешь её клиенту отдать.

20.04.2008, 14:55

Программа при создании объекта может передать ему ссылку на себя (this). Эта ссылка записывается в instance-переменную объекта, с помощью которой он будет потом дергать методы программы

20.04.2008, 16:44

1) а зачем тогда второй поток создавать, если только один объект обрабатывается.
2) ну синхронизировать надо будет (wait
otify)

@simplepilot · 20.04.2008, 16:58 **[ТС]**

Это нормальный вариант, но тогда получается слишком жёсткая взаимосвязь между классом создающим объект и самим объектом. То есть класс создающий объект и передающий ему ссылку this должен обязательно иметь набор синхронизированых методов с заренее определёнными названиями (ну хотя бы один метод) который будет
вызывать дочерний объект. Можно конечно вообще интерфейс для этого сделать специальный но как то это не эстетично

@simplepilot · 20.04.2008, 17:13 **[ТС]**

4 Kite: Вариант 1 хоть и аболютно не имеет смысла, может быть применён с целью обмануть начальника и сказать что у нас используются thread а как это детали (просто мне эти потоки не очень то вообще нужны, но начальник сказал что хочет их ! в категоричной форме)
Вариант 2: А нельзя ли по подробней. Можно ли сделать так что бы вызываюший пото узнал когда умер дочерний поток и что нибудь от него напоследок получил.

@simplepilot · 20.04.2008, 17:14 **[ТС]**

4 Kite: Вариант 1 хоть и аболютно не имеет смысла, может быть применён с целью обмануть начальника и сказать что у нас используются thread а как это детали (просто мне эти потоки не очень то вообще нужны, но начальник сказал что хочет их ! в категоричной форме)
Вариант 2: А нельзя ли по подробней. Можно ли сделать так что бы вызываюший поток узнал когда умер дочерний поток и что нибудь от него напоследок получил.

21.04.2008, 10:42

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

. А что касается того, что сказал начальник, так у моего друга начальник берет на работу только тех, кто программирует на асме, только потому, что какой-то гад сказал, что это типа круто и асма типа самый крутой язык.

@simplepilot · 21.04.2008, 12:31 **[ТС]**

Понимаешь, босс прочитал книжку про патерны ОО проектирования. И начал внедрять по поводу и без эти патерны. То есть у нас теперь везде объекты где надо и где нет. Так вот передача ссылки на себя, и вызов родитьльского метода, ни в какие патерны не лезет. То есть считается как бы признаком плохого дизайна. Ведь потомок обязан иметь родителя стандартного типа и не может быть создан без него (а это кстати в определённых случаях плохо) Вобщем я просто хотел узнать нет ли какого нибудь стандартного подхода к обмену сообщениями между детским и материнским процесом.
Как резюме я решил передавать детскому процесу все сведения о клиенте которому ему надо будет по окончании отослать ответ и пусть бадяется как хочет а как закончит пусть об этом сообщит сразу клиенту а основная программа об этом даже знать не будет. В принципе это хреново так как может быть куча процессов которые где то там болтаются и никто про них ничего не знает. Но для таких случаев есть кнопка reset

@koriun · 21.04.2008, 17:47

Hi

Если у вaс клиент-сервер средa, тo мoжнo и пoпрoбoвaт вaриaнт веб-серверoв.

кaкдa веб-брoузер пoсилaет зaпрoс веб-серверу, сервер oткривaет нoви socket , сoздaёт дoчерни пoтoк и передaет ему нoви socket, тaким oбрaзoм брoузер и дoчерни пoтoк рaбoтaют друг с другoм испoлзуя нoви socket. A oснoвнaя прoгрaммa прoдoлжaет следит нoвим зaпрoсaм.

@simplepilot · 21.04.2008, 20:46 **[ТС]**

Примерно так кстати я пока и думаю сделать. Но к сожалению они используют не сокетное соединение а связь по специальному протоколу где есть очередь входящих и выходящих сообщений. Так что пакет надо просто положить в очередь и он оттуда сам куда надо доберётся. Проблема что очередь одна а желающих туда чего нить засунуть больше. Так что буду смотреть можно ли её совместно использовать несколькими процессами. Конечно было бы оптимально что пихал в очередь кто то один. Не знаю может даже такой объект сделать - Пихатель в очередь и всем передавать ссылку на него. А у него сделать синхронизированый метод который все будут юзать. А возможно что и сама очередь синхронизирована - по крайней мере начальник рвёт рубашку и кричит что оно так и есть (доверия к его словам правда мало

@iZEN · 22.04.2008, 07:22

Ну а чем Вам не нравится стандартный механизм Подписчик-Уведомитель?
Схема уже заезженная:
0. Материнский класс имплементирует простой интерфейс слушателя, а дочерний класс должен вести список ссылок на 'интерфейс(ы)' слушателя(ей).
1. Материнский объект создаёт дочерний;
2. Материнский объект 'подписывается' на получение события дочернего объекта -- в дочернем объекте регистрируется подписчик(причём не сам подписчик, а интерфейс слушателя, который реализует подписчик);
3. Дочерний объект перед смертью рассылает подписчику(ам) уведомление о важном событии, используя ссылку(и) на интерфейс(ы) слушателя(ей);
4. Дочерний объект вычёркивает из своего списка подписчика(ов);
5. Дочерний объект умирает.

По поводу очереди...Может лучше организовать ПУЛ ожидания?

@simplepilot · 22.04.2008, 12:02 **[ТС]**

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

@simplepilot · 22.04.2008, 19:31 **[ТС]**

Спасибо всем поучаствовашим (посочуствовавшим). Резюме после совещания с босом:
Делать через Observer-Observable. То есть Главный процес наследует обсервер, а детский Observable. Что из этого выйдет выяснится 4го марта когда это надо будет сдавать :-)

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Desktop (MinGW): Рисуем цветные прямоугольники с помощью рисовальщика SDL3 на Си и C++ 8Observer8 17.03.2026 Содержание блога Финальные проекты на Си и на C++: finish-rectangles-sdl3-c. zip finish-rectangles-sdl3-cpp. zip	Символические и жёсткие ссылки в Linux. algri14 15.03.2026 Существует два типа ссылок — символические и жёсткие. Ссылка в Linux — это запись в каталоге, которая может указывать либо на inode «файла-ИСТОЧНИКА», тогда это будет «жёсткая ссылка» (hard link),. . .	[Owen Logic] Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ФедосеевПавел 14.03.2026 Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ВВЕДЕНИЕ Выполняя задание на управление насосной группой заполнения резервуара,. . .	делаю науч статью по влиянию грибов на сукцессию anaschu 13.03.2026 прикрепляю статью
SDL3 для Desktop (MinGW): Создаём пустое окно с нуля для 2D-графики на SDL3, Си и C++ 8Observer8 10.03.2026 Содержание блога Финальные проекты на Си и на C++: hello-sdl3-c. zip hello-sdl3-cpp. zip Результат:	Установка CMake и MinGW 13.1 для сборки С и C++ приложений из консоли и из Qt Creator в EXE 8Observer8 10.03.2026 Содержание блога MinGW - это коллекция инструментов для сборки приложений в EXE. CMake - это система сборки приложений. Здесь описаны базовые шаги для старта программирования с помощью CMake и. . .	Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .	Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .

@simplepilot 1 / 1 / 5 Регистрация: 22.07.2007 Сообщений: 366

	Возращаемое значение из Thread 20.04.2008, 13:48. Показов 1746. Ответов 12 Метки нет (Все метки) Программа работающая как backgraund process устроена так, что получая запрос пользователя в виде XML сообщения она создаёт на его основе объект, а потом запускает этот объект выполняться как отдельный процесс. То есть программа занята тем только что получает сообщение и далее обрабатывает его специальный объект, работаюший как отдельный процесс (thread). Но есть одно но, программа должна отослать обратно клиенту ответ. И этот объект работающий как thread должен его как то программе обратно отдать. А вот можно ли так что бы какой то дочерний процесс вернул создавшему его процессу какое то значение. При этом интересует две ситуации 1. Программа создаёт одновременно только один объект(дочерний процесс) и терпеливо ждёт когда он 'отстреляется' и отдаст ей результат. 2. Одновременно существует много объектов(дочерних процессов) и каждый из них как нибудь дёргает вызывающую программу. Типа - я отсрелялся, вот тебе строка результата, можешь её клиенту отдать. 0

Sergey_
	20.04.2008, 14:55
	Программа при создании объекта может передать ему ссылку на себя (this). Эта ссылка записывается в instance-переменную объекта, с помощью которой он будет потом дергать методы программы

Kite
	20.04.2008, 16:44
	1) а зачем тогда второй поток создавать, если только один объект обрабатывается. 2) ну синхронизировать надо будет (wait otify)

@simplepilot 1 / 1 / 5 Регистрация: 22.07.2007 Сообщений: 366
	20.04.2008, 16:58 [ТС]
	Это нормальный вариант, но тогда получается слишком жёсткая взаимосвязь между классом создающим объект и самим объектом. То есть класс создающий объект и передающий ему ссылку this должен обязательно иметь набор синхронизированых методов с заренее определёнными названиями (ну хотя бы один метод) который будет вызывать дочерний объект. Можно конечно вообще интерфейс для этого сделать специальный но как то это не эстетично 0

@simplepilot 1 / 1 / 5 Регистрация: 22.07.2007 Сообщений: 366
	20.04.2008, 17:13 [ТС]
	4 Kite: Вариант 1 хоть и аболютно не имеет смысла, может быть применён с целью обмануть начальника и сказать что у нас используются thread а как это детали (просто мне эти потоки не очень то вообще нужны, но начальник сказал что хочет их ! в категоричной форме) Вариант 2: А нельзя ли по подробней. Можно ли сделать так что бы вызываюший пото узнал когда умер дочерний поток и что нибудь от него напоследок получил. 0

@simplepilot 1 / 1 / 5 Регистрация: 22.07.2007 Сообщений: 366
	20.04.2008, 17:14 [ТС]
	4 Kite: Вариант 1 хоть и аболютно не имеет смысла, может быть применён с целью обмануть начальника и сказать что у нас используются thread а как это детали (просто мне эти потоки не очень то вообще нужны, но начальник сказал что хочет их ! в категоричной форме) Вариант 2: А нельзя ли по подробней. Можно ли сделать так что бы вызываюший поток узнал когда умер дочерний поток и что нибудь от него напоследок получил. 0

Kite
	21.04.2008, 10:42
	Ну ты ведь уже сам всё написал. В любом случае дочерним объектам передаётся ссылка на главный, а затем они вызывают синхронизированный метод главного, что и будет являться сигнал окончания работы дочернего потока. Если всё так просто как ты написал, то методы wait и notify даже не понадобятся. Чего тут не 'эстетично', да и вконце концов тебе не за 'эстетичность' платят. А что касается того, что сказал начальник, так у моего друга начальник берет на работу только тех, кто программирует на асме, только потому, что какой-то гад сказал, что это типа круто и асма типа самый крутой язык.

@simplepilot 1 / 1 / 5 Регистрация: 22.07.2007 Сообщений: 366
	21.04.2008, 12:31 [ТС]
	Понимаешь, босс прочитал книжку про патерны ОО проектирования. И начал внедрять по поводу и без эти патерны. То есть у нас теперь везде объекты где надо и где нет. Так вот передача ссылки на себя, и вызов родитьльского метода, ни в какие патерны не лезет. То есть считается как бы признаком плохого дизайна. Ведь потомок обязан иметь родителя стандартного типа и не может быть создан без него (а это кстати в определённых случаях плохо) Вобщем я просто хотел узнать нет ли какого нибудь стандартного подхода к обмену сообщениями между детским и материнским процесом. Как резюме я решил передавать детскому процесу все сведения о клиенте которому ему надо будет по окончании отослать ответ и пусть бадяется как хочет а как закончит пусть об этом сообщит сразу клиенту а основная программа об этом даже знать не будет. В принципе это хреново так как может быть куча процессов которые где то там болтаются и никто про них ничего не знает. Но для таких случаев есть кнопка reset 0

@koriun 1 / 1 / 0 Регистрация: 19.12.2007 Сообщений: 199
	21.04.2008, 17:47
	Hi Если у вaс клиент-сервер средa, тo мoжнo и пoпрoбoвaт вaриaнт веб-серверoв. кaкдa веб-брoузер пoсилaет зaпрoс веб-серверу, сервер oткривaет нoви socket , сoздaёт дoчерни пoтoк и передaет ему нoви socket, тaким oбрaзoм брoузер и дoчерни пoтoк рaбoтaют друг с другoм испoлзуя нoви socket. A oснoвнaя прoгрaммa прoдoлжaет следит нoвим зaпрoсaм. 0

@simplepilot 1 / 1 / 5 Регистрация: 22.07.2007 Сообщений: 366
	21.04.2008, 20:46 [ТС]
	Примерно так кстати я пока и думаю сделать. Но к сожалению они используют не сокетное соединение а связь по специальному протоколу где есть очередь входящих и выходящих сообщений. Так что пакет надо просто положить в очередь и он оттуда сам куда надо доберётся. Проблема что очередь одна а желающих туда чего нить засунуть больше. Так что буду смотреть можно ли её совместно использовать несколькими процессами. Конечно было бы оптимально что пихал в очередь кто то один. Не знаю может даже такой объект сделать - Пихатель в очередь и всем передавать ссылку на него. А у него сделать синхронизированый метод который все будут юзать. А возможно что и сама очередь синхронизирована - по крайней мере начальник рвёт рубашку и кричит что оно так и есть (доверия к его словам правда мало 0

@iZEN 1 / 1 / 1 Регистрация: 18.08.2007 Сообщений: 289
	22.04.2008, 07:22
	Ну а чем Вам не нравится стандартный механизм Подписчик-Уведомитель? Схема уже заезженная: 0. Материнский класс имплементирует простой интерфейс слушателя, а дочерний класс должен вести список ссылок на 'интерфейс(ы)' слушателя(ей). 1. Материнский объект создаёт дочерний; 2. Материнский объект 'подписывается' на получение события дочернего объекта -- в дочернем объекте регистрируется подписчик(причём не сам подписчик, а интерфейс слушателя, который реализует подписчик); 3. Дочерний объект перед смертью рассылает подписчику(ам) уведомление о важном событии, используя ссылку(и) на интерфейс(ы) слушателя(ей); 4. Дочерний объект вычёркивает из своего списка подписчика(ов); 5. Дочерний объект умирает. По поводу очереди...Может лучше организовать ПУЛ ожидания? 0

@simplepilot 1 / 1 / 5 Регистрация: 22.07.2007 Сообщений: 366
	22.04.2008, 12:02 [ТС]
	Насчёт слушателей мысль отнюдь не плохая, единственное а что будет если несколько уведомителей одновременно пошлют уведомление слушателю? Будет ли тут действовать обычные схемы синхронизации? А насчёт очереди, то тут вообще без вариантов так как классы для работы с ней написаны сто лет назад и использование её - это вещь вообще не подлежащая обсуждению - у нас в конторе это стандарт. 0

@simplepilot 1 / 1 / 5 Регистрация: 22.07.2007 Сообщений: 366
	22.04.2008, 19:31 [ТС]
	Спасибо всем поучаствовашим (посочуствовавшим). Резюме после совещания с босом: Делать через Observer-Observable. То есть Главный процес наследует обсервер, а детский Observable. Что из этого выйдет выяснится 4го марта когда это надо будет сдавать :-) 0