https://opennet.ru/openforum/vsluhforumID3/48102.html В статье (http://www.ibm.com/developerworks/ru/library/au-unixforks/index.html) представлено введение в многопоточное программирование, рассматривается использование POSIX-потоков в качестве замены вызову метода fork().<br><br>URL: http://www.ibm.com/developerworks/ru/library/au-unixforks/index.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=19807<br> https://opennet.ru/openforum/vsluhforumID3/48102.html#10 Fri, 16 Jan 2009 14:27:09 GMT Альтернатива<br>1) создали listen socket<br>2) создали shm, положили туда семафор<br>3) нафоркали сколько надо чилдов - в каждом fsm и trylock на семафоре вокруг этого сокета.<br>схема маштабируется как угодно<br>долго обрабатывается операция внутри fsm - сделай еще чилдов и вперед :)<br> https://opennet.ru/openforum/vsluhforumID3/48102.html#9 Fri, 16 Jan 2009 13:03:05 GMT Городят обычно с fork'ами и пайпами/shm. Если итоговые единицы исполнения имеют общие данные, однозначно потоки. Если можно форкнуться и забыть о дите пока то не сдохло, лучше fork(). В данном случае, как уже сказали, параллельность вообще не нужна.<br> https://opennet.ru/openforum/vsluhforumID3/48102.html#8 Fri, 16 Jan 2009 10:16:34 GMT &gt;для таких задач правиный FSM позволит вобще все сделать в одном процессе :)<br><br>Кстати, да. Буду знать. :-)<br> https://opennet.ru/openforum/vsluhforumID3/48102.html#7 Fri, 16 Jan 2009 10:13:30 GMT Можно сказать спасибо за статью.<br>Тема очень актуальна в связи со сложностью реализации хорошего "распоточивания" с правильным разделением ресурсов между потоками.<br>Например, файлы, сокеты и пайпы, доступны всем потокам.<br>И т.д.<br>Отсюда и нетривиальность решаемых задач.<br> https://opennet.ru/openforum/vsluhforumID3/48102.html#6 Fri, 16 Jan 2009 09:40:02 GMT для таких задач правиный FSM позволит вобще все сделать в одном процессе :)<br> https://opennet.ru/openforum/vsluhforumID3/48102.html#5 Fri, 16 Jan 2009 08:18:13 GMT и еще для кучи всего.<br>Не забываем fork() это изолированое адресное пространство - а pthread shared.<br>в результате ошибка в одном процессе не может повлиять на остальные, а в случае тредов - очень легко. да и локинг в случае тредов может быть далеко не тривильным.<br> https://opennet.ru/openforum/vsluhforumID3/48102.html#4 Fri, 16 Jan 2009 06:59:59 GMT fork() нужон для exec_ов или для функций работающих с файлами. <br><br>остальное треды, мьютексы, семафоры, атомарные, чё там ещё... <br> <br> https://opennet.ru/openforum/vsluhforumID3/48102.html#3 Fri, 16 Jan 2009 06:41:12 GMT &gt;баянистый сайт!<br><br>Ну почему же? Встречал людей ( привыкших к Win32API ), для которых сама идея fork'ать процесс выглядит дико. Так что, просто и доступно. ИМХО.<br>А вообще, fork, лично мне кажется проще многопоточности. И если, например, надо в час десяток клиентов обслужить и каждому, скажем, 100 байт передать, то самое оно, смысла не имеет городить что-то с многопоточностью.<br> https://opennet.ru/openforum/vsluhforumID3/48102.html#2 Fri, 16 Jan 2009 06:32:47 GMT &gt; чем устаревший метод fork()<br><br>Фразочка раскрывает недалёкость и некомпетентность автора.<br>Правильно говорить "старый добрый форк()", который в ряде случаев действительно использовать неэффективно.<br>