форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"еще вопрос по организации работы с сокетами"
Сообщение от vvk on 12-Фев-03, 15:04  (MSK)
вот такое хотел уточнить. я хотел бы, чтобы работа с сокетами не блокировала основной поток. у меня периодически должны отсылаться данные. пока есть такой вариант: делаю fork и в child-е запускаю отсылание данных. если что вдруг не так, ставлю в известность главное приложение - это отработано уже. Так вот вопрос - не слишком ли тяжеловесно? в приложении у меня создается xlib окошко и запускается while цикл обработки сообщений. Он ведь тоже будет в child-e? хотя по идее до него дело не дойдет - этот метод по завершении работы должен прибить child-a. Может более гуманно как то по другому поступать, или fork сойдет?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "RE: еще вопрос по организации работы с сокетами"
Сообщение от XMan on 12-Фев-03, 17:32  (MSK)
Как вариант можно сделать неблокирующий сокет. Типа: fcntl(sock,F_SETFL,O_NONBLOCK); Вобщем, "man 7 socket" на предмет O_NONBLOCK
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "RE: еще вопрос по организации работы с сокетами"
	Сообщение от vvk on 12-Фев-03, 20:08  (MSK)
	ну это врядтли. может я что то не понимаю, но я должен дождаться когда вся куча моих данных отправиться (я рассказывал в предыдущем постинге), а потом получить ответ. Кромк того, если порция не отправилась, я должен подождать 30 сек и повторить попытку. >Как вариант можно сделать неблокирующий сокет. Типа: > >fcntl(sock,F_SETFL,O_NONBLOCK); > >Вобщем, "man 7 socket" на предмет O_NONBLOCK
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "RE: еще вопрос по организации работы с сокетами"
	Сообщение от XMan on 13-Фев-03, 01:16  (MSK)
	В принципе, неблокирующий сокет пойдет. Если он не отправил или не принял, возвращается -1 и errno=EAGAIN. Правда, корд для твоей задачи получится слишком заумным :) Как вриант 1: сделать отдельный процесс, который будет работать с очередью сообщений, формируемой родителем. Если чего-то не отправилось, берется следующее сообщение. И так до конца очереди. Потом спим 30 сек и повторяем попытки. Как вариант 2: пользовать вместо процессов потоки (pthread_... в linux), если приложение слишком большое на твой взгляд.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "RE: еще вопрос по организации работы с сокетами"
	Сообщение от vvk on 13-Фев-03, 09:29  (MSK)
	ок, спасибо. заумный код не хочу - предпочитаю простоту и ясность :) так что для начала попробую создавать отдельные процессы, ну а если будут проблемы с производительностью - рефакторинг нас спасет. как говорится в XP оптимизацию надо оставить на потом, когда уже понятно, что надо оптимизировать. >В принципе, неблокирующий сокет пойдет. Если он не отправил или не принял, >возвращается -1 и errno=EAGAIN. Правда, корд для твоей задачи получится слишком >заумным :) >Как вриант 1: сделать отдельный процесс, который будет работать с очередью сообщений, >формируемой родителем. Если чего-то не отправилось, берется следующее сообщение. И так >до конца очереди. Потом спим 30 сек и повторяем попытки. >Как вариант 2: пользовать вместо процессов потоки (pthread_... в linux), если приложение >слишком большое на твой взгляд.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

5. "RE: еще вопрос по организации работы с сокетами"
Сообщение от SalieFF on 25-Фев-03, 13:59  (MSK)
>вот такое хотел уточнить. я хотел бы, чтобы работа с сокетами не >блокировала основной поток. у меня периодически должны отсылаться данные. пока есть >такой вариант: делаю fork и в child-е запускаю отсылание данных. если >что вдруг не так, ставлю в известность главное приложение - это >отработано уже. >Так вот вопрос - не слишком ли тяжеловесно? в приложении у меня >создается xlib окошко и запускается while цикл обработки сообщений. Он ведь >тоже будет в child-e? хотя по идее до него дело не >дойдет - этот метод по завершении работы должен прибить child-a. >Может более гуманно как то по другому поступать, или fork сойдет? А selectами/pollами не судьба разрулить линейный код?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "RE: еще вопрос по организации работы с сокетами"
	Сообщение от vvk on 25-Фев-03, 16:02  (MSK)
	не знаю. с selectами/pollами никогда не сталкивался. если расскажешь что к чему популярно - буду очень рад. >А selectами/pollами не судьба разрулить линейный код?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "RE: еще вопрос по организации работы с сокетами"
	Сообщение от SalieFF on 25-Фев-03, 18:26  (MSK)
	>не знаю. с selectами/pollами никогда не сталкивался. если расскажешь что к чему >популярно - буду очень рад. > >>А selectами/pollами не судьба разрулить линейный код? А там все просто. Создается массив сокетов, и вызывается poll (или селект, они одно и тоже делают, только реализации разные, для линукса poll лучше) с этим массивом и таймаутом, он отслеживает на всех сокетах 3 типа событий, сокет доступен для чтения (есть данные для забирания, recv не заблокирует прогу), для записи (можно передавать в него, send не заблокирует прогу), или на нем произошел ексепшн (закрылся там, законнектился). Если на одном из сокетов возникает нужное событие, или кончается таймаут, poll завершается с каким-нть кодом возврата. Таким образом можно в цикле крутить poll с маленьким таймаутом, если появились нужные события - производить действия над нужным сокетом, если не появились (или появились ненужные ;) занятся каким-то еще полезным и недлительным (для стройной проги - не дольше pollовского таймаута) делом. Вот тебе и линейная квантовая циклическая модель, которая параллельно обрабатывает тучу сокетов при этом не прибегая к разблокированию, форкам или тредам. Почитай manы, посмотри примеры, это очень аккуратный и экономичный подход.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.