Re[12]: IOCP: GetQueuedCompletionStatus и потоки
От: Michael Chelnokov Украина  
Дата: 09.08.07 15:54
Оценка:
Здравствуйте, TarasCo, Вы писали:

TC>Многопоточный сетевой сервер — это штука для большой нагрузки.


Скорее для людей с семью пядями во лбу, ездящих на сферических конях в вакууме
Потому как даже для больших нагрузок с точки зрения проекта в целом (учитывая реалии постоянно меняющихся требований по функциональности и человеческий фактор) лучше использовать многоПРОЦЕССНЫЙ сервер. Процессам надо общаться друг с другом? Именованные каналы (под Windows) или AF_LOCAL (под UNIX) вам в руки. Сердитость реализации на первых порах с лихвой окупается отсутствием перманентного гемора с порчей памяти и синхронизации в дальнейшем.
Re[13]: IOCP: GetQueuedCompletionStatus и потоки
От: Gomes Россия http://irazin.ru
Дата: 10.08.07 05:12
Оценка:
Ого как вы накинулись на бедные потоки
Я бы сказал что зависит от конкретных условий, бывает что и одного потока за глаза. Но многопоточные сервера необходимы, и их нужно уметь писать. И только через это умение будешь стремиться к простоте (фигасе написал ). Это как, например, профессиональные бильярдисты, предпочитают бить простые шары, но могут забить и от потолка. Да, писать такие штуки сложно, но можно и нужно.
Re[14]: IOCP: GetQueuedCompletionStatus и потоки
От: TarasCo  
Дата: 10.08.07 06:09
Оценка:
G>Ого как вы накинулись на бедные потоки
Холивар!!!! Холивар!!!!

G>Я бы сказал что зависит от конкретных условий, бывает что и одного потока за глаза. Но многопоточные сервера необходимы, и их нужно уметь писать. И только через это умение будешь стремиться к простоте (фигасе написал ). Это как, например, профессиональные бильярдисты, предпочитают бить простые шары, но могут забить и от потолка. Да, писать такие штуки сложно, но можно и нужно.


Если программирование было делом избранных, и если бы в эти избранные попадали люди по спортивной ( т.е предельно жестко конкурентной ) системе, то естественно, они должны писать супер круто и, наверное, от них нужно это требовать и платить за это также достойно. У нас ситуация в большинстве случаев другая. Я не скрою и скажу, что лично я люблю удовлетворять любопытство за счет работодателя. Но я хоть знаю азы в своем деле. А многие идут дальше — они обучаются в процессе работы . Представте, что водитель фуры на трассе решит поупражняться в экстремальном вождении? Вместо того, что ему нужно просто тупо давить на газ . Или представте повара ресторана с книгой "о вкусной и здоровой пище" в руках?

PS: К топикстартеру я эти слова не отношу. Человек для себя может делать все, что угодно. И все мы что то делаем в первый раз и ошибаемся. Конференция для того и нужна, чтобы решать возникшие технические трудности, так что все сказанное мной — это ни в коем случае не камень в его огород лично. Это вопрос скорее к руководителям и архитекторам проектов. Они ведь во всем всегда виноваты?
Да пребудет с тобою сила
Re[15]: IOCP: GetQueuedCompletionStatus и потоки
От: Gomes Россия http://irazin.ru
Дата: 10.08.07 06:38
Оценка:
Здравствуйте, TarasCo, Вы писали:

TC>Холивар!!!! Холивар!!!!


Да какое там. Мнения то у нас в принципе совпадают: умеешь — пиши, не умеешь — учись и пиши
Re[16]: IOCP: GetQueuedCompletionStatus и потоки
От: Michael Chelnokov Украина  
Дата: 10.08.07 11:14
Оценка:
Здравствуйте, Gomes, Вы писали:

G>Да какое там. Мнения то у нас в принципе совпадают: умеешь — пиши, не умеешь — учись и пиши


Не, вопрос вообще-то был о целесообразности потоков, работающих с общими данными, как таковых.
Re[17]: IOCP: GetQueuedCompletionStatus и потоки
От: Gomes Россия http://irazin.ru
Дата: 10.08.07 12:52
Оценка:
Здравствуйте, Michael Chelnokov, Вы писали:

MC>Не, вопрос вообще-то был о целесообразности потоков, работающих с общими данными, как таковых.

Да я понял конечно. Но только, по-моему, достаточно сложно ответить на этот вопрос в общем. Чтобы сказать хоть что-то определенное, надо, ИМХО, брать определенную клиент-серверную архитектуру, делать многопоточный сервер, тестировать, делать однопоточный (многопроцессный?), опять тестировать, сравнивать. Потом брать другую архитектуру и т.д.. И в конце анализировать результаты и делать выводы.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.