В статье (http://www.ibm.com/developerworks/ru/library/au-unixforks/in...) представлено введение в многопоточное программирование, рассматривается использование POSIX-потоков в качестве замены вызову метода fork().

URL: http://www.ibm.com/developerworks/ru/library/au-unixforks/in...
Новость: http://www.opennet.me/opennews/art.shtml?num=19807

• Введение в многопоточное программирование,pavlinux, 22:18 , 15-Янв-09
  • Введение в многопоточное программирование,Damon, 09:41 , 16-Янв-09
    • Введение в многопоточное программирование,_umka_, 12:40 , 16-Янв-09
      • Введение в многопоточное программирование,Damon, 13:16 , 16-Янв-09
        • Введение в многопоточное программирование,_umka_, 17:27 , 16-Янв-09
    • Введение в многопоточное программирование,Staff, 16:03 , 16-Янв-09
• Введение в многопоточное программирование,andr.mobi, 09:32 , 16-Янв-09
• Введение в многопоточное программирование,pavlinux, 09:59 , 16-Янв-09
  • Введение в многопоточное программирование,_umka_, 11:18 , 16-Янв-09
• Введение в многопоточное программирование,XoRe, 13:13 , 16-Янв-09

баянистый сайт!

>баянистый сайт!

Ну почему же? Встречал людей ( привыкших к Win32API ), для которых сама идея fork'ать процесс выглядит дико. Так что, просто и доступно. ИМХО.
А вообще, fork, лично мне кажется проще многопоточности. И если, например, надо в час десяток клиентов обслужить и каждому, скажем, 100 байт передать, то самое оно, смысла не имеет городить что-то с многопоточностью.

для таких задач правиный FSM позволит вобще все сделать в одном процессе :)

>для таких задач правиный FSM позволит вобще все сделать в одном процессе :)

Кстати, да. Буду знать. :-)

Альтернатива
1) создали listen socket
2) создали shm, положили туда семафор
3) нафоркали сколько надо чилдов - в каждом fsm и trylock на семафоре вокруг этого сокета.
схема маштабируется как угодно
долго обрабатывается операция внутри fsm - сделай еще чилдов и вперед :)

Городят обычно с fork'ами и пайпами/shm. Если итоговые единицы исполнения имеют общие данные, однозначно потоки. Если можно форкнуться и забыть о дите пока то не сдохло, лучше fork(). В данном случае, как уже сказали, параллельность вообще не нужна.

> чем устаревший метод fork()

Фразочка раскрывает недалёкость и некомпетентность автора.
Правильно говорить "старый добрый форк()", который в ряде случаев действительно использовать неэффективно.

fork() нужон для exec_ов или для функций работающих с файлами.

остальное треды, мьютексы, семафоры, атомарные, чё там ещё...  

и еще для кучи всего.
Не забываем fork() это изолированое адресное пространство - а pthread shared.
в результате ошибка в одном процессе не может повлиять на остальные, а в случае тредов - очень легко. да и локинг в случае тредов может быть далеко не тривильным.

Можно сказать спасибо за статью.
Тема очень актуальна в связи со сложностью реализации хорошего "распоточивания" с правильным разделением ресурсов между потоками.
Например, файлы, сокеты и пайпы, доступны всем потокам.
И т.д.
Отсюда и нетривиальность решаемых задач.